Audit the containerisation code

The worker currently uses [bubblewrap](https://github.com/containers/bubblewrap) (using linux cgroups) for privilege separation, and `systemd-run` (using linux user namespaces) for limiting of volatile resources (time, memory). While this is a nice, lightweight setup, it's not an existing setup, and it has not been audited.

If anyone has the expertise to have an informed opinion about these kind of systems, please help!

The system is as follows: (all is in the `play-haskell-worker/` directory)
- The `bwrap-files/ubuntu-base` directory is a chroot populated with an Ubuntu installation, set up in the `chroot` target of [`Makefile`](https://github.com/tomsmeding/play-haskell/blob/master/play-haskell-worker/Makefile) using `bwrap-files/chroot-initialise.sh`. Hopefully the precise workings of this step do not actually matter for the security property below.
- The worker starts `bwrap-files/stage-1.sh` with one argument: a file descriptor that is open for writing in the `stage-1.sh` process (say P).
- The worker sends a bunch of untrusted bytes on stdin of P.
- The worker expects a bunch of untrusted bytes on stdout and stderr of P, as well as on the pipe of which one end is that writable file descriptor.
- The worker kills the container.

Assuming that the worker (and the server and the client webpage after that) handle the output bytes safely, the security property is (loosely formulated) that no matter what bytes are sent to P, the outside of the container is not harmfully affected. That is to say: the container does not perform network activity, puts no lasting data on disk, and maybe other things that I haven't thought of.