Update addressbook to use ->open_sync()

This allows us to kill off all pretence of supporting the 'only_if_exists'
argument. Which we didn't actually support anyway, and which is going to
be even further from being supportable when I move to using a GInitable to
open the database at instantiation time.
Use GInitable to initialise addressbook

We apparently get asked for revision and locale information before it's
actually opened, and clients will crash if we just return NULL. So open
the sqlite database at instantiation time, like the file backend does.
Port addressbook to EBookSqlite
Fix build for oab-decode-test, port it to EBookSqlite
Move dset handling inside ews_decode_addressbook_record()
Use (hashed) PidTagEmailAddress for OAB item UID

The PidTagSmtpAddress isn't always unique.
Pass GInputStream to decoder functions instead of assuming priv->fis

If we want to optimise the decode a little and also use data twice, we'll
probably want to create a GMemoryInputStream for each record. We're doing
a lot of seeking due to ews_oab_read_upto() already, and it'll only get
worse if we take the SHA1 of each record as well as processing it.
Use GMemoryInputStream for processing records, calculate SHA1 on each
Optimise EWS GAL update not to rewrite unchanged records

Store the SHA1 of the binary data in bdata in the sqlite. When processing
the new OAB file, if the bdata already matches then do nothing to the
existing record.

Before starting to process the OAB file, build a GHashTable with all the
UIDs which already exist in the database. Remove them from the GHashTable
as they are seen while processing the OAB file. At the end, any which are
still left in the GHashTable are deleted.

The value in the GHashTable is the SHA1, and is freed either when a
matching record is decoded or at the end when we process the hash table
to remove all remaining entries, with the append_to_list() helper
function.

This should *drastically* improve the performance of the GAL update.
Avoid processing OAB records which already exist

By checking the SHA1 before generating the EContact we can halve the time
taken to process the Intel GAL from about 50s to about 25s.

The extra data is now the key in one GHashTable, and freed with that
hash table. While the uids are the key in the other and freed with that.