Extract a blockio package from lsm-tree

[jorisdral]

Both the HasBlockIO API and simulation will have to be exposed in some manner to users of the lsm-tree library. The former so that users can open a session, and the latter to make sure that users can also run lsm-tree with a file system simulation. Recall openSession:

lsm-tree/src/Database/LSMTree/Common.hs

Lines 182 to 189 in 5e72f1f

	openSession ::
	forall m h. (IOLike m, Typeable h)
	=> Tracer m Internal.LSMTreeTrace
	-> HasFS m h
	-> HasBlockIO m h -- TODO: could we prevent the user from having to pass this in?
	-> FsPath -- ^ Path to the session directory
	-> m (Session m)
	openSession tr hfs hbio dir = Internal.Session' <$> Internal.openSession tr hfs hbio dir

^ the answer to the TODO here is: I don't think that in general we can prevent the user from having to pass in HasBlockIO. Initialising a HasFS is linked to initialising a HasBlockIO, but the way in which we do this for the real file system and simulated file system is different:

lsm-tree/blockio-api/src/System/FS/BlockIO/IO.hs

Lines 12 to 17 in 5e72f1f

	-- | Platform-dependent IO instantiation of 'HasBlockIO'.
	ioHasBlockIO ::
	HasFS IO HandleIO
	-> IOCtxParams
	-> IO (HasBlockIO IO HandleIO)
	ioHasBlockIO = I.ioHasBlockIO

lsm-tree/blockio-sim/src/System/FS/BlockIO/Sim.hs

Lines 148 to 155 in 5e72f1f

	simHasBlockIO ::
	(MonadCatch m, MonadMVar m, PrimMonad m, MonadSTM m)
	=> StrictTMVar m MockFS
	-> m (HasFS m HandleMock, HasBlockIO m HandleMock)
	simHasBlockIO var = do
	let hfs = simHasFS var
	hbio <- fromHasFS hfs
	pure (hfs, hbio)

So we can't hide HasBlockIO from the user, it seems. And, as @wenkokke suggested, we should probably expose the API and simulation in a separate package.

I had initially hoped we could re-export the necessary blockio definitions from the main lsm-tree library while keeping the sub-libraries hidden. However, since we shouldn't export the simulation (with dependencies on test libraries) from the public API, we would have to create a public sub-library with just the blockio simulation. At this point, it's probably better to have a separate package.

BWT, I also made blockio-sim a public sub-library of blockio-api (i.e., now the component is identified by blockio:sim). The reasoning here is that there are very few definitions in blockio-sim, and one would have to depend on blockio-api anyway to do anything with the simulation. As such, you could argue it's better not to separately publish blockio-sim. As far as I understand, Hackage has also gotten better at support for sub-libraries, see https://hackage.haskell.org/package/io-classes for example.

[jorisdral]

I should put some text here if we want to proceed with this PR