hvt: Address space layout randomization

[mato]

As part of general hardening, it is desirable to implement ASLR for the hvt target and tender. Current general purpose OSes (Linux, FreeBSD, OpenBSD) have converged on "Static PIE" as the implementation technique of choice, so we should follow their lead here.

A rough plan of the steps involved:

1. Add support to the build system (compiler toolchain checks, linker scripts) to build unikernels as "Static PIE" or equivalent (-static-pie itself is merely the host toolchain's idea of how this should work; we need the component parts, i.e. -fPIE from the compiler, and the ability to build the final ELF as an ET_DYN executable with immediate binding).
2. Add support for loading a minimal subset of ET_DYN executables to the ELF loader, initially at a fixed base address equal to the current layout (0x100000).
3. Add support to the hvt bindings to perform the minimal amount of relocation required at startup, along the lines of e.g. musl rcrt1.o. This will require passing the base address from the tender to the guest.
4. At this point we have "Static PIE" (or equivalent), but no ASLR. Verify that/work with the downstream toolchains (mainly OCaml) are able to cope with this setup.
5. Decide on an address space layout and implement ASLR. This will require some thought on what the guest-virtual to guest-physical to host-virtual mapping should look like, with a view to minimizing complexity in the tender, and taking into account host hypervisor limitations on memory slots, while having a sufficient amount of address space available to randomize into.