Turn the standalone kernel into a library

[tomaka]

Close #689

Before this PR, the standalone kernel is cross-platform. It uses only the build target (e.g. x86_64-unknown-multiboot2) to determine which environment to expect, and documents it.
The kernel also assumes that the linker will provide the __bss_start and __bss_end symbols. Again, this is documented.

After this PR, the standalone kernel is no longer a binary but a library. It provides a macro called __gen_boot! that generates the code necessary to boot the kernel. The difference compared to now is that this macro can be passed more parameters than just the target, which will result in less guessing.
For example, the __bss_start and __bss_end symbols are now explicitly provided as parameters to the macro.
The user, here the standalone kernel builder, at the same time passes these symbols and ensures that they indeed exist, therefore resulting in less magic.

The intention behind this PR to later make it possible for the standalone kernel builder to parse a DeviceTree file, pass the appropriate memory ranges and CPUs count to the macro, and make sure that the appropriate drivers are included in the kernel. cc #283

The other intention is to make it possible for the standalone kernel builder to generate test kernels that just boot, test something, and shut down. Again, this is possible thanks to the fact that the kernel is passed everything instead of guessing what its environment is.

Another side effect is that in the future the standalone kernel builder can be truly standalone and fetch the kernel from crates.io. It would simply be a CLI program, which you can cargo install. You pass some parameters, and boom you get a kernel. No need to actually clone the source code.

[tomaka]

Just like #692, this broke the x86_64 kernel. Still investigating.