Features/Thunderbird/Contact integration

There are numerous challenges with this project. A UI for a contact that is composed of potentially overlapping fields from different sources is made even more difficult by the fact that it's unlikely that fields from each contact provider will map 1-to-1.

A simple, yet powerful UI for the above is one of the primary challenges for this project.

One of the likely consequences of creating a contact provider API is users have contacts duplicated across multiple address books.

We would like to make it possible to merge / integrate contacts across different contact providers.

Contact provider address books could then be thought of as contact groups, allowing contacts to be assigned arbitrarily to them (assuming that the contact providers are not read-only).

1. A user adds a contact provider to an address book that already has some contacts in it. Contacts are merged where applicable. Changes made locally to contacts and fields associated with a contact provider are automatically pushed to that contact provider.
   
2. A user adds a contact provider to an address book that already communicates with one or more other contact providers. Contacts are merged where applicable. The user can view the contacts that were merged, and make any corrections or resolve any ambiguities that may have arisen from the merge.  Any information brought in from this new contact provider will not be sent to any other contact provider.
   
3. A user adds a new contact to their address book. During creation, the user has the ability to define what contact providers the new contact will be associated with.  These contact providers are automatically updated with this new contact.
4. A user deletes a contact in their address book. Contact providers that Thunderbird has permissions to push to have this contact removed. For providers that do not allow us to delete contacts, Thunderbird instead hides that contact from view.
5. A user wants to remove a contact from one contact provider, but not from others. The user disassociates the contact from the contact provider, and the contact is deleted from that provider (if possible - if not, it's simply made hidden). Changes to that contact are no longer pushed to that provider.
6. A user wants to add a contact with a large number of e-mail addresses and phone numbers. Unfortunately, one or more of their contact providers do not support more than 5 e-mail address and phone fields. While creating this contact, these limitations are shown to the user, who can then choose a subset of e-mail addresses and phone numbers to push to those providers.
7. A user has added some contact providers whose supported fields do not map 1-to-1. When editing their contacts, they can easily see and manipulate which fields are being written to each provider.
   

On Merging

For this version, we will assume that two contacts are automatically-mergable if they share at least one e-mail address.  Down the line, we might do something smart with string comparison and confidence ratings, but e-mail address matching will do for now.