Better modeling for KVO collection changes

This abstracts over Cocoa's built-in collections with `<RACCollection>` and `<RACOrderedCollection>` protocols, and then models changes to them with `<RACCollectionMutation>` and `<RACOrderedCollectionMutation>`. There are ordered and unordered versions 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 kind of changes can be really granular, it's likely that they'll be getting applied constantly.
 1. **Granular KVO notifications.** Mutation makes it really easy to generate lossless (or mostly lossless) KVO notifications when updating a collection.

Plus, “immutable” transformation can always be emulated by creating a mutable copy of the input.

This API will eventually be useful for granular table/collection view updates.

@dnalot @iMartinKiss @indragiek

**To do:**

 - [x] Finish up documentation
 - [x] Implement automatic changes for view-based `NSTableView`s
 - [x] Add `UITableView` bindings
 - [x] Add `UICollectionView` bindings
 - [x] Unit tests