ChangeProcessor Architecture Update

[jleandroperez]

We've got several issues that would require tracking the number of retries per change, and/or could use some optimizations in the way we store pending changesets:

• Issue Improve Retry Mechanism #336: Requires nuking the version from the change, if it wasn't accepted the first time.
• Issue Retry sending pending changes after timeout #227: Requires tracking the number of retries, so the library doesn't get into a retry loop.
• Issue Performance issue - batching #274: Related to SPPersistentMutableDictionary impact.

Plus, it would be great to:

• Update all of the code we've got that uses the Change Dictionary, to use explicit getters, instead of relying on key-value.
• Encapsulate SPChangeProcessor's keyWithoutNamespaces method into a proper entity.
• Potentially, deprecate the helper SPPersistentMutableSet. Only if we do manage to keep the same functionality, without performance impact.

Let's address this scenario in a feature branch:

• Wrap the remote changes into a new class: SPChange
• Refactor / Rebuild SPPersistentMutableDictionary to handle SPChange. Potentially, this means that we'll build a class called SPChangeStorage
• Measure performance impact against the current mechanism.
• Implement fetch requests to replicate the current usage we've got in SPPersistentMutableSet, and measure its performance with over 10k entities.
• Update Unit Tests
• Integrate with the rest of the library.
• Make sure that legacy metadata is migrated into the new mechanism.