Do not compose create with op

[gkubisa]

The problem is that the create operation contains initial data rather than a snapshot and apply requires the first param to be a snapshot. So, the original implementation worked only for the types which have the same type of initial data and snapshots.

[coveralls]

Coverage decreased (-0.005%) to 96.487% when pulling d1ca2ae on Teamwork:fix-tryCompose into 68bde00 on share:master.

[ericyhwang]

From the PR review meeting, @gkubisa linked #214 as an example of where this can cause an issue, with the custom text-tp2 OT type.

@nateps's comments:

• Problem with compose is that you lose information about the context [of the original ops].
• Also, it's possible for one of the ops to fail.
• Safest extreme is to compose nothing, but composing is good in many situations like typing text, or where you might want things to go together to the server.
• Possible for something to rely on compose, that would be broken by not composing.
• It's an interesting question as to whether compose should operate on creates. The spec doesn't allow it, but it is a performance benefit.

Greg suggests, if we do want to keep the performance benefit, adding an applySerialized function to OT types, so that we can use it if it's available and not break the spec.

@nateps says that after talking about it, let's just merge this.

[gkubisa]

Just to clarify, I agree with @nateps that the performance impact of this change is negligible.

I mentioned applySerialized and its potentially significant impact on performance in the context of updating ShareDB to correctly support the OT Types spec. See #214 (comment) for more details.

[curran]

Suggest to close as stale.