Avoid committing no-ops

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.

Start with the client submission and version handling in lib/client/doc.js, especially OP_SUBMIT_REJECTED and the non-invertible-type rollback paths, then inspect the ack handling in lib/agent.js. Trace how a no-op is committed, transformed, acknowledged, and broadcast. Done means the behavior is defined for no-op submissions without unnecessary database writes or broadcasts, while client versions and pending operations remain correct.