Speed up metadata implementation

Even after being sped up in a previous pull request, RKDictionaryByMergingDictionaryWithDictionary is a large hotspot in several areas (see #2065).  It appears to me that, for the most part, the metadata is only accessed as part of valueForKeyPath: in RKMappingSourceObject.  It seems like it would be possible then to maintain a list of metadata dictionaries, and just iterate until we find a value for the entire key path.  This should in basically all circumstances give the same result as actually merging dictionaries, and it would avoid the need for merging.  The first metadata dictionary to return a value would "win", so that would correspond to the last dictionary passed to the merging method before (since that would overwrite previous values when merged).

One bugaboo was the implementation of parentObjectForRelationshipMapping, which actually uses valueForKey: to build up a chained list of RKMappingSourceObject listings.  To support that, I actually needed a wrapper class so it could implement valueForKey: and valueForKeyPath: correctly.  I'm not sure under what circumstances that is used -- is it key paths like "@parent.@parent.@metadata.XXX" ?  There might be better ways of implementing that to avoid the need for the wrapper, or at least make it more created on demand.

Timings before:
(Device) Mapping 5000 students with relationship mapping: 28.091627
(Simulator) Mapping 5000 students with relationship mapping: 3.926955

and after:
(Device) Mapping 5000 students with relationship mapping: 26.182683
(Simulator) Mapping 5000 students with relationship mapping: 3.718350

Note that the "before" timings include a previous fix which speeds up finding a target object; that avoids a call to RKDictionaryByMergingDictionaryWithDictionary, so if that is not applied then the effect of this change is even greater.

This is mostly passive, except the ability to obtain the metadata as a single dictionary, and to reset it directly on an RKMappingOperation while in progress.  However, most code will provide metadata through other interfaces I'd guess, and should work the same.

This is a more substantial change, so it may bear more investigations to see if there are even more appropriate ways of implementing these features.  I just wanted to at least show what improvements were possible, and start some discussion on it.  Also, it removes several hotspots from profiling, which will let me more easily find other speed improvements.

I don't think there's anything inherently wrong with this approach, I just think the function needs documentation.