[WIP] Better modeling for KVO collection changes

**:warning: NOT READY TO MERGE :warning:**

This abstracts over Cocoa's built-in collections with `<RACCollection>` and `<RACOrderedCollection>` protocols, and then models changes to them with the `RACCollectionMutation` and `RACOrderedCollectionMutation` classes. There are ordered and unordered versions of a couple of KVO change kinds.

Although this might seem like over-abstraction, it means that new collections _and_ new mutation types can be added in the future (or by consumers) without affecting existing code.

I chose to focus on _mutation_ instead of immutable transformation for two reasons:

 1. **Performance.** I hate this line of argumentation, but the performance of copying really can add up. Since these changes can be really granular, it's likely that they'll be getting applied constantly.
 1. **Granular KVO notifications.** Mutating a collection—instead of transforming it—makes it really easy to generate lossless (or mostly lossless) KVO notifications based on the changes made.

This API can be used to perform granular table/collection view updates.

@dnalot @iMartinKiss @indragiek @robrix 

**To do:**

 - [ ] Finish up documentation
 - [ ] Unit tests