Bug 699597 - EBookSqlite: Add indices on family_name, nickname, given_name and file_as

The Evolution address autocompletion uses these, and we really want it to
be fast. So enable indices on the *unlocalised* column by default.
Bug 699597 - EBookSqlite: Fix queries to use LEFT JOIN where appropriate

This fixes the test case added in commit 5f9f5b52. We need to use LEFT JOIN
in the cases when we need to include records that have no auxiliary data, but
we really don't want to do that unless we need to because it's slow.

So add some logic to track it. The interesting question, as we process each
clause, is whether this clause is *mandatory* — does it *have* to match, for
a given record to show up in the final results?  In the simple case of a
single 'AND', all its subclauses *are* mandatory. In the simple case of a
single 'OR', its subclauses are not (because a record can make its way into
the results without matching any specific subclause).

Since we need to err on the side of caution, the simplest approach was
just to bail and use 'LEFT JOIN' whenever we are referencing an auxiliary
field inside any 'OR'. But that was suboptimal in some cases where the
*same* auxiliary field was being tested twice. So we check whether all
subclauses of an 'OR' are on the same field, and we don't make it fall
back to LEFT JOIN when that's the case.

It helps that we never support NOT on auxiliary field checks, which would
make the whole thing a lot harder to think about...
Bug 699597 - EBookSqlite: Use UNION for autocomplete queries

The sqlite query planner does a really bad job here. It ought to realise
that it could do the searches on fields in folder_id directly from the
folder_id table, indices and all.

So recogise this case for ourselves and rephrase it so the query planner
doesn't do so badly. If it's just a logical 'OR' of a bunch of conditions,
some of which are auxiliary fields and some are not, then use a basically
hand-crafted query using UNION to make sure sqlite notices the fast way
to do it.

This takes the autocomplete query on my 237000-entry EWS GAL from about
1700ms to 6ms.

Yes, it's an icky special case and it *really* ought to be considered
a sqlite bug. But it's an important special case because the user is
waiting for it while they type and delays are really noticeable. And
it's a *big* win.

Discussed at
https://www.mail-archive.com/sqlite-users@sqlite.org/msg86350.html
https://www.mail-archive.com/sqlite-users@sqlite.org/msg86643.html