[TIMOB-1894] Android: support read-write contacts

assigning to Herr T for milestoning.

for me the priority should be upgraded to high, this situation leaves cross-platform apps crippled on one platform

Research for M04

This was put into M04 only for research purposes to try to scope the effort. After review, my assessment is that this is will be a fairly major effort.

• iOS has it "easy" -- each Person is backed by a ref to an actual address book object, an ABRecordRef (AB being the prefix for address book stuff). So when properties are changed on Titanium's TiContactsPerson, the properties are then just changed on that object. Android doesn't do this provider stuff with objects, rather via queries in provider database system. So when changes are made to properties of a PersonProxy in Titanium Android, we can't just turn around and update an in-memory object.
• Similarly, iOS has it "easy" because when it comes time to save any and all changes made to one or more contact persons during the session -- i.e., when the Titanium JS code calls Titanium.Contacts.save() -- they just need to call ABAddressBookSave and all changes to ABRecordRefs up to that point are committed. In the case of Android, we'll have to work harder in the sense of somehow caching changes and applying them at save() time.
• Android, since 2.0, has the notion of aggregated contacts. When you present the contacts picker to the user, for example, you get a listing of aggregated contacts. When the user selects a contact, they get an aggregated contact record in our PersonProxy. If the Titanium JS code then modifies properties on that PersonProxy and Titanium.Contacts.save() is called, which of the aggregated contact entries should be updated? We have to think about that carefully. (Note: If I use my Android 2.2 phone and go to People, pick a contact which I know is an aggregate and click the menu and choose "Edit", I'm prompted with a list of the underlying (non-aggregate) entries and asked to select which one I want to edit. So you can see this is an issue.)
• We're currently supporting pre-2.0 contacts because we support Android 1.6. (Android Contacts API went through a major overhaul starting in 2.0.) This is already a PITA and will be more so for writable contacts. For example, the most straightforward way to try to cache changes and apply them later with Titanium.Contacts.save() would be to cache them in an array list containing Android ContentProviderOperation instances and then use ContentResolver.applyBatch when Titanium.Contacts.save() is called. None of that stuff is available in Android 1.6.

Assigning for further milestoning.

This is a natural fit for the next release when we drop support for Api Level 4.