Instead of merging dictionaries, keep a list of separate metadata dictionaries and implement valueForKeyPath: to iterate through them.  This is a bit more substantial change, and one situation may still be a bit inefficient -- when creating a parentObject for a deep hierarchy, we need to create some standin objects which implement valueForKey: the same way, rather than intercepting at the RKMappingSourceObject class.  Not sure if there is a way around that.
Further speed changes; the creation of the metadata dictionaries is fairly expensive; a specialized object can be faster.  Also, it allows us to create just one and re-use the instance whiel iterating over a to-many relationship.  Secondly, the metadata used for a to-one relationship is constant, so can be a static instance created just once.  Refactor some of the code used in the previous commit and document new public methods.
A few further changes, mainly to cut down on the metadatas object being created in the top-level RKMapperOperation by using a custom class instead of creating NSDictionaries each iteration.  This is a little bit faster, especially with many objects at the top level.  Did require changing a private method signature which needed unit test updates.
Merge pull request #2077 from carllindberg/2065-AvoidMergingDictionaries

Speed up metadata implementation
The checking to set unchanged values is actually kind of expensive, especially for the non-CoreData situations (since calling -valueForKey will allocate objects for scalar properties) and it's rearely needed.  To speed things up, add a property on RKMappingOperation which indicates if the destination object came from a data source or not, then use that in the data source methods in order to determine whether to check for changed values.  CoreData will continue to use isTemporaryID for any managed objects, but we can now avoid checking for unchanged values in many cases.  Also, store the result from the data source once in the main method, instead of checking for every attribute.
Change getter method on new property to be "isNewDestinationObject" per PR comments.
RKMapperOperation has more duplicate code from RKMappingOperation than I realized.  So, I did need to expose the new property to that class to be consistent with it.