Test framework for kernel (and user-level OS services)

[dbittman]

It would be nice if we could leverage rust-standard behavior for writing things like #[test] in the kernel and in user-level OS services (for testing low-level Twizzler libraries like twizzler_abi) and integrate this with the build system so we can easily run the test framework as part of a github actions run.

[dbittman]

The branch feature/test-framework now has some initial work on this. The following additions have been made:

1. changes to xtask to allow building test executables for twizzler libraries that can get loaded into the initrd.
2. init now looks for a test list object, listing the test executables that xtask finds.
3. the kernel now allows for exiting qemu using qemu's little ioport hack.
4. modified the kernel to parse incoming bootloader command line
5. kernel checks to see if --tests is present, and if so, exits qemu if a panic occurs (or if a magic syscall is made) with a code
6. init exits qemu with either success (1) or failure (3) to indicate if tests pass or fail.

This does not include a test framework for the kernel, which is a little trickier since it can't be hosted (the default rust test library expects a hosted compiler). Will work on that next.

This also doesn't currently allow for test harnesses in executables, only in libraries. We can work on that at a later time.

Since qemu's exit code can be controlled by the guest, we can hook this into a CI system without too much pain. In theory, anyway.

Note: this also does make assumptions that enough of the system works to even run the tests. Thus, if test mode is enabled, the kernel prints out a couple special messages ("!!! TEST MODE ACTIVE") so that a monitor script can inspect the output and time-out the CI if needed.

[dbittman]

Oh, also note that the current implementation is super hacky. Will fix that later, this is just trying to get the needed features to work at all :)

[dbittman]

This has been implemented in #56, #58.