EContact: Added support for phonetic names fields.

VCards can contain fields with phonetic version of contact family and
given names.
It should be possible to use them as sorting keys for database queries
as for some languages like e.g. Japanese it is not possible to generate
correct sorting order even using ICU library, as the same Kanji
characters can have different pronunciation e.g.:
* 淳子 (Junko)
* 淳子 (Atsuko)
* 淳子 (Kiyoko)
* 淳子 (Akiko)
More information can be found here:
http://www.localizingjapan.com/blog/2011/02/13/sorting-in-japanese-%E2%80%94-an-unsolved-problem/

VCards supports additional fields that can contain phonetic version of
names allowing for correct sorting order in aboive cases.
As these fields are not standardized different VCard providers can use
different fields to store phonetic information e.g.
Android phones, Google Contacts and iCloud is using
"X-PHONETIC-FIRST-NAME" and "X-PHONETIC-LAST-NAME" fields,
BlackBerry Z10 uses "X-FAMILYNAME-SOUND" and "X-GIVENNAME-SOUND",
also according to
http://www.mcpc-jp.org/news/pdf/TR-015vCard_Guideline_V1.00.pdf
"X-YOMI-FNAME" and "X-YOMI-LNAME" can be used.

This patch adds phonetic family and given name attributes to
EContact. Values of these attributes can be parsed from all VCard fields
mentioned above. Additionally when VCard does not contain any of these
fields, synthetic ones will be created using contact family and given
name
respectively - in that way these fields can be safely used as sort
key in database queries.
EContact when converted back to vCard will store phonetic names using
"X-PHONETIC-FIRST-NAME" and "X-PHONETIC-LAST-NAME", if source VCard
was using different fields for them, they will also be preset in
resulting VCard.
EBookSqlite: Added support for transliterated regex queries.
EBookSqlite: fixed memory leak in ebsql_ref_from_hash.

ebsql_ref_from_hash is always returning NULL, even if instance for given
database was found in hash and its reference count was increased,
creating memory leak.
EBookSqlite: Use Any-Latin;Latin-ASCII transliterator.

Currently used Any-Latin transliterator is not removing all national
characters e.g. ø đ ł ð from transliterated fields.
Using Any-Latin;Latin-ASCII transliterators combination results in
substituting above characters respectively into o d l and d.