libtracker-sparql: Fix handling of partial FTS deletion

Due to the SQL interface offered to update external content and content-less FTS tables, updates on FTS columns must happen as 2 separate updates, one to delete tokenization data from the tree, and another to update.

Due to our own current implementation details, the FTS table is synchronized per-row, meaning that we always want a FTS update after a FTS delete, in order to synchronize other properties properly. Fix the code to force one in place, instead of relying on loosely related paths to set it.

This was unnoticed because most often FTS deletes are either a part of an FTS update, or part of a resource deletion (thus no FTS properties are left for the resource).

But with the right circumstances, a FTS deletion may come alone, thus it would not trigger the later expected FTS update. This may unbalance the FTS tree, causing SQLITE_CORRUPT on later updates. An example of this is:

INSERT DATA { a nfo:InformationElement ; nie:title 'b' ; nie:identifier 'c' . }

DELETE WHERE { nie:title ?t }

Fix this situation by always scheduling a FTS update after a delete. The FTS update will be opted out on actual full deletes otherwise (concretely by early out due to the FTS update having no actual changes).

Fixes: #361 (closed)