This change adds the ability fetch a snapshot by time. The motivation
for this is that fetching a document by time is quite a "natural" way
to think about document history, and allows us to - for example - fetch
multiple documents as they were at a given time, without having to
look up their exact version numbers first.

We add a new `Connection.fetchSnapshotByTimestamp` method, which
follows a very similar route to `Connection.fetchSnapshot`, and where
possible, as much code is re-used as possible:

  - both methods use a subclassed child of `SnapshotRequest`
  - both methods have their requests handled by the same machinery in
    `Connection`
  - both methods in the `Backend` have ops applied by a common method,
    but use their own methods for calls to middleware

In order to make this feature possible at scale, this change also adds
two new methods to the `MilestoneDB` interface:

  - `getMilestoneSnapshotAtOrBeforeTime`
  - `getMilestoneSnapshotAtOrAfterTime`

These methods are used to fetch milestone snapshots either side of the
requested timestamp, which means we only need to fetch the ops between
the two of them to reach the desired timestamp.

In the case where a milestone database is not being used, then fetching
a snapshot by timestamp is still possible, but it will fetch all the ops
for a document, and keep applying them from v0 until the timestamp is
reached, which is not particularly scalable.

This change removes or renames `shouldBreak` calls. In `Backend`, for
clarity we instead pre-filter ops, and just pass around the ops we want
to be applied to a snapshot.

In the `MemoryMilestoneDB`, these functions are extracted and renamed to
more descriptive break condition names.

The function for building a snapshot from ops is useful, and has no
dependencies on `Backend`. This change moves it into the `ot` module,
where it will be a bit more discoverable and can be reused.