Random notes

• I duplicated the build process used by gnu-efi, because that way we avoid problems with linking (we can use objcopy on an ELF binary instead of needing a full-featured PE32+ linker).
• For some reason, UEFI on QEMU cannot read cdrom images (it's entirely possible I'm doing it wrong! open an issue if you know a solution!), so I build a hard drive image instead.
• The runtime is set up so that you can use heap right from the start. To achieve this, the kernel duplicates the UEFI's identity mapping to the upper half of virtual memory, without changing the original mapping, and the heap allocator uses UEFI BootServices to allocate if it runs out of pages to use before ExitBootServices(), but automatically translates the address into upper half. After ExitBootServices(), all free memory is just dumped into that same allocator.
• We use identity mapping (well, actually it's at an offset, but whatever) in top half for access to physical memory (mainly the allocator stuff and page tables, but later that might include inter-process memory copies etc). This limits the amount of physical memory we can use (to less than about 2^47 bytes on x86_64, so no biggie). This is fine for now, but might need to be fixed in distant future. If future me is reading this in a future where I need to lift this restriction: Have fun! Mwahahahahaha. Sincerely, past you.
• It will be possible to use std in the near future, with runtime failures for unsupported things (work in progress). Why std with most of the std thingies not working? Because the no-std environment is just downright inconvenient, that's why.