Cardano Updates

Change “this” to “the” for “disk I/O complexity”

They're over a year old, so it probably doesn't hurt to set them to a more
recent date.

Bump `s-r-p` for `blockio-uring`

And add a test, and immediately start using the alternative calculations in the
prototype.

This config value is largely ignored for now, but it is passed to places where
we'll need it in the next few commits.

And remove the old calculations.

The new functions can compute the maximum run size for a tiering/levelling run
given a level number, or conversely, can compute the level number of a
tiering/levelling run given the run's size. These alternative calculations are
parameterised by the maximum write buffer size, which is configured using the
`configMaxWriteBufferSize` field of `LSMConfig`.

As a sanity check for the run size calculations, some properties are added to
the prototypes test suite.

These alternative calculations are also closer to the real implementation of the
merge schedule.

Bump `s-r-p` for `blockio-uring`

`StateMachine`: fix a test failure where an injected error is swallowed

The test failure can be reproduced using the following seed:

```
cabal run lsm-tree-test -- \
  -p '$0=="lsm-tree.Test.Database.LSMTree.StateMachine.propLockstep_RealImpl_MockFS_IO"' \
  --quickcheck-replay="(SMGen 11798857835899383018 1561550946174790845,97)"
```

The test fails because an injected error with an `FsReachedEOF` type is
swallowed by the `openTableFromSnapshot` public API function. We fix the test
failure (for now) by not generating errors of that type.

At some point we should think of a more principled approach to this type of
swallowed error. `FsReachedEOF` is not an error type that any of the `HasFS`
primitives can throw in practice when using the real file system, but `fs-sim`
error injection *can* throw this error type. Maybe `fs-sim` shouldn't inject
this type of error.

and an `isFsReachedEOFError` utility function.

Change the name extension of action files to `yml`