Change RKObjectMapping's propertyMappings accessor method to simply return the internal array, rather than making a full copy on every access.  Several methods of RKObjectMapping itself call it like a regular accessor (to get the count, for example) and it gets called a tremendous number of times during mapping operations.  This saves a lot of memory during those operations, plus alloc/dealloc/retain/release/autorelease overhead.
Revert two unintended changes in the last commit

This reverts commit 54cbc9e4130382537eea95f78c24f084031adb07.
Speed up RKDictionaryByMergingDictionaryWithDictionary a bit.  Primarily by avoiding an extra copy of the dictionary at the end, but also don't use -enumerate (has a nested autorelease pool), and use NSDictionary methods and not KV.
Minor performance improvement; check first to see if it's a special key at all before the series of hasPrefix calls, since most of the time it will not be a special key.  The CFStringHasPrefix function did show up as a minor hotspot, and this helps a tiny bit.
Change RKObjectMapping propertyMappings property to be immutable, to avoid having accessor be expensive (pay more of a price during setup instead, instead of the hot mapping code).
Whoops, fix things for the "self" key.  And check for empty keys, though those are illegal with KV on regular objects -- could be OK for dictionaries.
Revert change to RKObjectMapping metadata property.  This loses some of the performance gain (as each sub-operation will now make a copy) but it's less prounounced on a device.
Make RKMappingOperation be a straight NSObject subclass instead of NSOperation; we were really only using the cancellation methods from the superclas (and -start).  There is actually a 10% penalty on the entire mapping process just for having NSOperation as a superclass for some reason, at least when using a lot of nested operations.
Add comment as requested in PR comments
Example of a slightly modified logging setup which would then allow bridging to other logging systems, and an implementation of a CocoaLumberjack bridge.  Bridges can be assigned at runtime.
Fix compile warning in unit tests after this change.
The code which gets the "representation" object ready for the data source's targetObject method is expensive, and the argument is ignored in a non-CoreData situation.  To speed up other code, add a new data source method which is the same except does not provide the representation, in case the data source can respond without it.  If it cannot, we fall back to the previous behavior.  Even CoreData situations can be helped if there is a non-CoreData mapping involved.
Make the current logging class a static variable with accessor functions, rather than exposing the global.  Change the core logging method to match the existing LCLNSLogging_RK class which is out there; that class could probably be used as-is for the logging class.  Move the RKLogging definition to the logging config header; it has to be there since the lcl typedefs are only defined by the lcl headers (which import that config file), which need to be defined before we can declare the RKLogging protocol, which in turn should be defined before we use that in the core logging macro definition, which I think must be defined before the rest of the lcl definitions.  So I'm not sure we can move it elsewhere and still use the lcl typedefs.  Moved the implementations to RKLog.m.
Not sure what I was thinking... we can move the RKLogging definitions to RKLog.  The #defines that use them come earlier, but so long as they are declared before the log macro is actually expanded anywhere, it is fine.
Merge branch 'development' into LumberjackBridge
Update the Xcode project file to add the new lumberjack class, and remove an obsoleted .h/.m .
Add comments per PR request
parentObjectForRelationshipMapping: was being called twice; once to obtain the destinationObject, and once in the subsequent call to mapNestedObject.  Just create once and pass to both methods.  Also, it was being created once per loop in a to-many situation; it only needs to be created once.  Also, speed up parentObjectForRelationshipMapping: a little bit.
Merge pull request #2069 from carllindberg/2065-FasterSourceValueForKey

Speed up RKMappingSourceObject KeyValue
Merge pull request #2066 from carllindberg/2065-ObjectMappingPropAccessor

Change RKObjectMapping's propertyMappings accessor method to simply retu...