Restructure the code into a library

[Ivan-Velickovic]

The following PR is a draft and attempts to re-work the entire project into a VMM library. The motivation for this is that coming up with a "one size fits all" generic VMM is not ideal. Instead, it is ideal to provide users with a library (and plenty of examples) which they then use to produce their own VMM for their use case (a minimal seL4CP VMM is only ~100 lines of code).

The reason I've made this a draft PR is so people know what to expect (and can provide feedback if they wish).

Yet to be done is the following:

• Audit architecture specific parts of the VMM (once the RISC-V port is done this will confirm whether we've made the right abstractions)
  • Left for when we actually add a new architecture.
• Eliminate most if not all of util.c and util.h
  • Maybe some minor clean up left, but all that's left really is the libc functions that we need. What to do about seL4CP projects that need libc functionality is a broader question and not just to do with VMM. It's fine to roll our own memset and memcpy but they are definitely not as performant as the optimised libc ones.
• Restructure the examples.
  • All the library code in src/ and a separate top-level examples/ directory that contains all the example VMMs (e.g a simple generic one just for booting a basic Linux machine with serial input/output, a virtio example VMM, a passthrough example VMM etc).
• Use newlib or a some pre-packaged libc instead of rolling our own memcpy and memset. So far I have no luck with getting newlib to work.
  • Attempted, failed. Will revisit at a later stage.
• Examples of using other build systems. So the simple example will have at least Makefile, CMake and Zig to actually demonstrate how to incorporate the VMM into an existing project.
• Update the manual and README accordingly.
• CI needs to be updated once the examples are restructured.
• See if Renode is in a good enough state to be used in examples or whether we just stick to QEMU for now.
  • Doesn't look like it's mature yet, see Use Renode for simulating the examples #15.
• Address Tim's issues/fixes with the manual

Questions to answer:

• How to distribute and package library?
  • Dealing with this later once VMM becomes more stable (and actually ready for other people to use)
• How to deal with large binary images for examples? Do we complicate the examples by having a separate top-level image directory to avoid blowing up the size of the repository? Is there actually much image re-use between the examples if we do this generalisation?
  • Tracking issue Dealing with the large size of the repository #14, not something to deal with while the VMM is still changing a lot and not stable.
• In general, how to handle information flow between the system description (e.g. guest RAM size) and the VMM code/library.
  • Am in the process of thinking about this, we are internally building more complex systems and will use those to inform how to deal with abstracting over the seL4CP system description.