Support in-line editing of to-many forms

Previously it appeared that inline edits happened, but backing form object was not updated.

Also in order to support safe editing, we also validate that the backing collection value type will not have any potential ordering issues. Specifically, collection types that do not have a defined order will show add/delete controls.
Prevent crash caused by deleting multiple dup objects, other deleting issues

When deleting a row from a to-many subform, -removeObject was being used to remove that row from the collection. If the backing collection was a set, that was fine. However, if that backing collection was an array, then removeObject will remove all instances of that object from the array. Which could easily be referencing that object multiple times at multiple indexes. That scenario immediately crashes because the backing array would have fewer items after removeObject than the corresponding section in the tableview.

This is easy to reproduce in the sample app but just clicking add twice on the phone number section to add two blank entries and then deleting one of them. Since they are both blank, they will be -equal and the app will crash.

This also brings up the issue of what would happen if the backing store was an NSSet or NSDictionary, however. Neither guarantee the order of items returned by allObjects. Although deleting an item is unlikely to change the order of returned items, it is theoretically possible. If this did happen it would have bad consequences for the to-many list. So this commit also removes the ability to delete items from the to-many items unless the backing store is an ordered collection (NSOrderedSet or NSArray).

Conflicts:
	FXForms/FXForms.m
Use FXFormFieldInline field property to determine editability

For a to-many field, FXFormFieldInline's traditional meaning doesn't make sense: we are already, pretty much by definition, displaying the fields of the collection inline. This commit repurposes that FXFormFieldInline property for to-many fields, using it to indicate that the list of detail fields should be inline editable: allowing adds/deletes to the collection and inline editing for NSStrings.

I have very mixed feelings about this. I like neither overriding the existing meaning of FXFormFieldInline, nor do I like the fact that it doesn't provide fine grained control. But I think that displaying a read-only array of detail lines via an FXForm is a critical use case. And "allow editing inline" doesn't seem to far a stretch from "display inline".

I am happy to rework this commit for any reasonable alternative. The other alternatives I considered are:

* Add additional property types to allow fine-grained control regarding whether adds are allowed, deletes are allowed, and editing is allowed. This probably the best long-term solution, but I don't want to introduce any more changes to the properties in order to support one-to-many. I will leave any additional property decisions to @nicklockwood.

* Allow the collection type to determine whether editing inline is allowed. Only allow adds/deletes from NSMutableArray/NSMutableOrderedSet and disallow them from NSArray/NSOrderedSet. Its cognitively easy to understand/explain, but I feel that this approach violates the core design principle of FXForm: allowing you to use the objects you already have and just add a couple of methods (like -fields) to tailor what you want. This approach would make any NSArray property difficult to edit.

* Add an optional protocol method(s) to allow the user's FXForm to decide at run-time whether adds/edits/deletes are allowed. This is relatively easy to implement within FXForm, fairly easy to implement for users, and offers the most flexibility (users could allow deleting some rows, but not others). But it introduces even more complexity than adding properties, so I'm not willing to consider it seriously.
Update to-many example app

* Move form initialization to view controller (so we can have different informationForm objects)
* Add additional subform examples for NSMutableArray, NSOrderedSet, NSMutableDictionary to demonstrate and test various collection types and edge conditions (see comments in -fields)
Merge branch 'feature/onetomanysupport' of github.com:bartvandendriessche/FXForms into feature/onetomanysupport