This is needed after the fts4 changes

e.g. nie:url instead of fully qualified URLs

e.g. nie:title:0 nid3:contentType:24 nid3:contentType:43

FTS functions and other SQL functions like COUNT() don't
mix well, so handle it more generically by joining with the
FTS table at the outmost level, so those functions are handled
separately.

FTS support on Tracker is now implemented using external content
support available in sqlite >= 3.7.9 FTS4.

FTS tables created this way fetch data from a single table/view,
for this purpose an intermediate view has been created to
interface with the FTS table. As this view is mainly queried by
ID (both when populating the FTS contents, and when querying
throught the FTS table), queries are fast enough on it.

As FTS indirectly points to the data on the real tables where tracker
data is stored, strings themselves are stored only once in the database,
so there is no impact in database size when compared to the previous
custom FTS code. Performance had little changes too from testing.

Recent sqlites (>3.7.9) with FTS support compiled have all
what Tracker requires to handle FTS, so only compile it
optionally if no FTS support was detected in the sqlite library.

Use a define that actually exists around tracker_fts_init(), which
also checked for the inverted value.

It would previously miss the FTS binding, depending on the order
of the clauses. so something like { ?u fts:match 'foo'; a nie:DataObject }
would return results whereas { ?u a nie:DataObject ; fts:match 'foo' }
didn't.

The internal TrackerParser must be per-cursor, as several cursors
may be opened simultaneously.

this function takes up to 3 optional parameters after the
object, the first 2 parameters are the starting/ending text
for the match (defaults to <b></b>), and the third one
modifies the ellipsis text (defaults to <b>...</b>)

The outer query will call the functions that require a full row
scan only with the elements returned by the inner query, so
it would perform better with OFFSET and LIMIT

commit/rollback should happen now with the rest of the
operations, and update_init() isn't necessary anymore.

If a new property is with tracker:fulltextIndexed, we need to add
a new column for it in the FTS table.

As ALTER TABLE on virtual tables is only able to do renamings,
resort to creating a temporary table, and dump the old values
into the new table, which is then renamed.

This function takes the offsets() output and the FTS property
names in order to produce the output as expected by Tracker.
the fts:offsets() sparql function has been adapted to use it
underneath

This is now used in FTS searches to provide the rank based on
the matched columns and their respective property weight.

there is now one column per ontology property with FTS enabled,
the column name is that of the property.

This function removes from the FTS table the text from a resourceid/propid
pair.

The code isn't yet feature complete, but cleans up the tracker
integration with the FTS module, which means that fts3* files
are taken verbatim from sqlite, and are licenced as such.

GUPnP-DLNA 0.9/0.10 changed a lot internally and thus does not deliver a
GstDiscovererInfo anymore but instead has a new API that allows guessing the
profile from an existing GstDiscovererInfo, so most of the additional logic
can be dropped.

Fixes GB#691847, tracker-extract: Port to new gupnp-dlna API

Fixed GB#692409, New: playlist extractor should index playlist title if
available

Fixes GB#692603, Search can not find pdf files using author names

https://bugzilla.gnome.org/show_bug.cgi?id=692210

Fixes GB#691807.

Fixes GB#691804

See: https://live.gnome.org/GnomeGoals/LibsecretMigration

Fixes GB#679870, libsecret migrations

Based on a patch from Trever Fischer.

Fixes GB#690170, Add nfo:MediaList type to .m3u playlist files