Updated Greek translation
Updated Marathi Translations
Updated Czech translation
NEWS update for 3.13.6
Post-release version bump
Updated Hindi translation
[Win32] Provide a simple password store

org.freedesktop.secrets is not available under Win32, thus have there
at least a simple password store.
Bug #737279 - DRA not working
Updated Latvian translation
Updated Bengali (India) translation
Correct compiler flags for libedataserver-private.la

The compiler flags for .cpp files should not use the same warnings
as the .c files.
Bug 653157 - Enable extra compiler warnings in maintainer mode only

The 'extra' means also deprecated warnings. Those are not interesting
for non-developers.
Updated Polish translation
Add libedbus-private.la into LIBADD where needed

This fixes a build break on some systems (for example Debian)
after changes in commit a2790163af4d3f375a778055d0e2699207dfd050.
Fix UOA accounts accumulating on startup.

Contributed by an Ubuntu user:
https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1373908
Updated Polish translation
imapx_is_duplicate_fetch_or_refresh: Fix incorrect bit-flag test
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