Limit resident memory usage

You can easily crash this `mueval` based lambdabot by e.g. `[1..]`; it will run out of memory.

Using `mueval`'s `--resource-limits` flag no longer works with GHC >= 8 because Haskell programs compiled by it allocate 1 TB `VIRT` at startup, and `ulimit`/`setrlimit()`'s `RLIMIT_RSS` to restrict only resident memory, not `VIRT`, only works on Linux < 2.4.30.

The only remaining way to do this is appears to be `cgroup`s. Those require `root`, but that is OK for some use cases.

Creating a memory-limited cgroup is as easy as

```
cgcreate -g memory:lambdabot
echo 320000000 > /sys/fs/cgroup/memory/lambdabot/memory.limit_in_bytes # 320 MB
echo 0 > /sys/fs/cgroup/memory/lambdabot/memory.swappiness
cgexec -g memory:lambdabot
```

Doing this in `strace` shows that this really just does `mkdir` and `cat` equivalents in the `/sys/fs/cgroup/memory` dirs, so we can easily do that from Haskell; the `cgexec` in particular writes its own PID into `/sys/fs/cgroup/memory/lambdabot/tasks` and then calls `exec`. This too we can do from Haskell.

* But it requires that the lambdabot executable accepts a flag to start only a `mueval` process (so that the server can re-`exec` itself with that flag).
* (This is different from what `mueval` does now, which is just to spawn a new thread and `setrlimit()` for that; we can't do that with cgroups v2, because they are per process, not per thread.)
* Mueval has a high startup time because it starts a GHCi session with the `ghc` API. That means if we want it to be fast, this requires that the subprocess and the server process communicate expressions and results using some IPC mechanism, so that they can do so multiple times within the same GHCi session. Only a resource exhaustion will then force the session to be re-started expensively.