fix(sparql-anything): accept an empty output as no triples unless --load could not be checked

[ddeboer]

convert() rejected any process whose --output was empty, on the assumption that SPARQL Anything exits 0 whenever it cannot read an input. A chunk whose rows the query filters out entirely writes a 0-byte output too, and was then reported as an unreadable input, aborting the run.

Measured on v1.2.0 and v1.2.0-RC1, the assumption is narrower than that. A missing or unparseable chunk makes SPARQL Anything exit 1, which the converter already turns into a failed run. The one input it does not fail on is --load: a missing file is logged, the query runs without the data, and the exit code is 0. A query that reads only loaded data (the GeoNames ontology job) then writes an empty output, indistinguishable from a query whose FILTER matched nothing.

So the converter now checks the one file that matters, once per job and before any process starts:

• A relative load path is relative to workDir for the task runner and the converter alike, so a missing or empty one fails then, naming the file.
• An absolute load path is the runner’s – under a container’s mount, say – and one the converter cannot find on its own side proves nothing, so the job runs and an empty output from it still fails.
• Every other empty output is accepted as “no triples” and contributes nothing to the concatenation. A missing output file still fails.

Chunks are not checked: SPARQL Anything fails on them itself, and a 0-byte chunk still yields the Facade-X root. The earlier rule that a job without chunks could never produce an empty output is gone as well; it encoded what one caller’s query happens to return.

Docs updated under “Loading existing RDF” and “How a conversion runs”.

Fix #820