custom serialization of OT types (Nate's proposal)

[DetweilerRyan]

This pull request is an attempt to add support for custom serialization of OT types per @nateps elegant proposal as outlined here #108 (comment).

The type API changes would be:

1. Apply is overloaded to take either serialized data or deserialized data: apply(serializedData, op) -> serializedData' and apply(deserializedData, op) -> deserializedData'. Internally, the version that deals with serializedData can call deserialize on the input and serialize on the output to start with.
2. Add: deserialize(serializedData) -> deserializedData
3. Add: createDeserialized([initialData]) -> deserializedData

And the changes to ShareDB would be:

1. Doc::ingestSnapshot should call type.deserialize before setting doc.data if defined
2. Doc::_otApply should call type.createDeserialized instead of create if defined

[coveralls]

Coverage increased (+0.09%) to 95.922% when pulling a012d1d on Retrium:feature/add-custom-serialization into 0769524 on share:master.

[roark]

I just wanted to chime in and say awesome addition @DetweilerRyan.

I had recently written a custom OT type and was hoping to be able to keep a deserialized Immutable.OrderedMap client side for rapid React rendering.

Once I saw your new pull request I immediately ran some local tests with a modified ot-number type that uses Immutable.Map and it worked beautifully. Very excited about this addition to ShareDB.

[DetweilerRyan]

Thank you @roark. Glad to hear others are rolling their own ot types. Immutable data structures are a really great fit for ot types. We use Immutablejs for all of our custom ot types at @Retrium.

I have to give credit to @xylude who actually implemented @nateps's proposal. All I did was write the tests.

[minicuper]

@roark - How can we take a look at the new ot-type?