Avoid committing no-ops

[alecgibson]

At the moment, if you submit a no-op (or two ops collide, resulting in one of them being transformed into a no-op), ShareDB will commit this to the database.

This has some downsides:

• pointless DB writes
• can cause unneeded retries if other ops are submitted at the same time, which wouldn't need to be transformed because it's a no op, but they still have to fetch the no op and try to transform themselves (against a no-op) to catch up to the correct version
• no-ops are also then broadcast to other subscribers, using unneeded bandwidth and possible transforms on remote clients

It would be nice to (optionally?) skip committing no-ops to the database to avoid the above.

The main issue with this is that clients expect every submitted op to increment the version (which wouldn't be true in this case), so we'd need to add some machinery around telling the client that their op was no-oped and they shouldn't increment the version (maybe we can extend the ack message?).

The lazy way to do it is to return an OP_SUBMIT_REJECTED (or create a new similar error code), but this would only work on invertible types, since non-invertible types would get a hard rollback, and lose any pending ops.