Bug 735809 - Only export symbols starting with 'e_' in libebook-contacts
Bug 730438 - Remove Coverity scan TOCTTOU races from file handling code

There are various places in EDS where Coverity has detected TOCTTOU (Time
Of Check To Time Of Use) races in the file handling code, typically where
we do a stat() and then some other operation (e.g. open()) on the same file.
Apart from using extra syscalls unnecessarily, this approach is prone to
(quite unlikely) races where the file is created/destroyed between the stat()
and the following call. Instead, we should just examine the return value
from the following call more closely, and delete the stat() call.
Bug 735659 - EBookSqlite should ignore leading zeros when looking for phone number

EBookSqlite parses phonenumbers using libphonenumber - result of this
operation depends on currently set locale.
Some countries use leading 0 as area code prefix required when number is
presented in national format (without country code) e.g. in United
Kingdom.
This leading zeros may lead to wrong search queries if locale is not set
correctly and number in address book is stored in international format
and search query tries to find it using national format.
For example UK's phone number +44 2033445566 will be stored in user
address book in form - national number: 2033445566, country code: 44.
If user wants to query this number using national format -
02033445566 (with leading zero, e.g. number in such format could be
retrieved from users phone call log) result of operation depends on
currently set locale.

If system locale will be set to en_GB this number will be parsed using
en_GB as default region before making query which will lead to parsing it
into national number 2033445566 and country code 44 (the same like in database).
As EBookSqlite before making query is removing country code from numbers
for which default region was used, search query will look like:

... WHERE (phone_list.value_phone = '2033445566')

which will correctly find contact.

On the other hand the same search query won't return expected result
when system locale will be set to other locale than en_GB, e.g. en_US,
in that case 02033445566 number will be parsed into national number
02033445566 and country code 1, leading to a query

... WHERE (phone_list.value_phone = '02033445566')

Leading zero(s) won't allow to correctly find contact from address book.
EBookSqlite should remove them before making query, but leading
zeros shouldn't be removed from E164 values in contacts vCards.

This change adds additional parameter to
e_phone_number_get_national_number that indicates if leading
zeros should be removed from national number.
EBookSqlite code is updated to use national number without leading zeros
when creating search index.
Bug 735342 - camel: Fix potential integer overflow found by Coverity scan
Bug 736116 - Add EBSQL_DEBUG=timing
Bug 735344 - camel: Fix potential integer overflow found by Coverity scan

The headerlen is the difference between two pointers, so needs to be a
gintptr. Found by Coverity.

Coverity issue: #1061266