Enhance SPChangeProcessor Error Handling

### Description

The goal of this Pull Request is:

- [x] Capture and relay any errors that might arise while applying a remote diff.
- [x] Redownload the latest version for the entity that has errors.
- [x] Update the `processVersions` mechanism, so it doesn't overwrite local data, but rebase's local changes instead.

#### SPChangeProcessor Enhancements:
1. Updated ErrorHandler API. We're now capturing errors triggered while processing remote diffs.
2. Implemented new 'Entity Re-Download + Rebase' flow, to be triggered if a remote diff cannot be applied.
3. Implemented SPChangeProcessor Unit Test.
4. Updated SPDiffer API.
5. Updated SPMember superclass + subclassess API.
6. Minor code style update.
7. Fixed several Static Analyzer warnings.
8. Nuked dead code.


#### SPIndexProcessor Enhancements:
We've updated the `processVersions` method, which is used both during index processing, and it's now being triggered if SPChangeProcessor cannot apply a remote diff.

For each one of the versions retrieved, we're either inserting the new object, or performing a 'Rebase' sequence for local objects with a state that doesn't match the remote version.

Detailed steps for the rebase mechanism outlined below:

1. Calculate Delta: LocalGhost > LocalMembers
2. Load the full Remote Member Data
3. If the delta from step (1) is not empty, then let's attempt to rebase + apply localDiff
3.1. Calculate Delta: LocalGhost > RemoteMembers
3.2. Transform localDiff: LocalGhost >> RemoteMembers >> LocalDiff (equivalent to git rebase)
3.3. Attempt to apply the Local Transformed Diff
4. Update the ghost with the remote member data + version

**Note:** SPIndexProcessor enhancements were pushed in [this pull request](https://github.com/Simperium/simperium-ios/pull/295), and merged into the '291-change-processor-error-handling' banch, for convenience, since both issues are tightly coupled.

#### Legacy Re-Index Behavior:

For the record, this was the old `processVersions:` behavior:

1. If it's the first time the bucket is sync'ed (that is, pre-existant data before integrating Simperium), the ghostData field is updated with the remote ghost.
 1. If the SPManagedObject instance implements the `shouldOverwriteLocalChangesFromIndex` selector (and returns YES), we override the local data with the remote data.
 2. Otherwise the object is marked for processing: the delta between the local data and remote data will be sent to the backend, resulting in the local version to be sync'ed to other devices.
2. If it's not the first time the bucket is sync'ed, and local ghost version doesn't match wit
h the remote version, local data is overwritten.

Good practice to avoid accessors in init methods.