libtracker-data: Optimize easily catchable idempotent deletes
From the main commit:
Operations like "DELETE WHERE { <urn> ... }" can be tiptoed if we know
that <urn> is not a known resource yet, avoiding it's full evaluation.
These operations are a fairly common result from using TrackerResource
(e.g. ensuring multivalued properties are in a clean slate), they are
common enough that it's prominent in first-index tracker-miner-fs-3
perf records, e.g.:
15.79% 0.01% pool-tracker-mi libtracker-sparql-3.0.so.0.100.0 [.] translate_DeleteWhere
With this change in place, the same situation becomes:
3.70% 0.07% pool-tracker-mi libtracker-sparql-3.0.so.0.100.0 [.] translate_DeleteWhere