sel4vm: Remove vspace dependency

[kent-mcleod]

This is a breaking change but is probably worthwhile to consider:

Removing the vspace_t dependency from libsel4vm and libsel4vmmplatsupport
and interacting with the vspace objects directly mostly resolves a series of issues
and don't really introduce any significant new problems for guests or a client vmm
other than needing to update vmm drivers that expect to use the vspace objects.
It also provides a reasonably small stepping stone for eventually removing more of
sel4_libs as discussed recently (https://sel4.discourse.group/t/sel4-virtualization-support-current-efforts/665/3)

vspace_t is an abstraction that wraps seL4 vspace objects and provides
the following functionality:

1. Mapping intermediate page table objects automatically
2. reserving regions for future mapping
3. Helper functions for creating OS objects like ipc buffers and stacks
4. Tracking reserved regions in the address space like kernel window
   mappings
5. Unmapping vspace entries indexed by virtual address
6. Creating shared mappings from one VSpace into another vspace indexed
   by virtual address
7. Automatic placement of anonymous memory regions (eg mmap)
8. Automatic allocation and mapping of any internal book-keeping data
9. self-hosted or remote management of Vspaces where a vspace can refer
   to the current process address space or a different address space.
10. A way to iteratively and dynamically map frames from another vspace
    into the callers vspace and call a callback function with the mapped
    window as an argument. The mapping is then removed when the callback
    returns.

Unfortunately there are the following issues:

• The book-keeping data allocation can only happen through a vspace_t
  instance. For book-keeping a VM's vspace, the host must then also
  have a vspace_t for managing its own vspace, a host may not want this
  level of dynamism
• The book-keeping data doesn't currently do anything clever for large
  frames and still keeps a unit of data for every 4k range of memory
  used in the vspace. So a 2MiB mapping would have 512 duplicate
  book-keeping entries, and a 1GiB would have 51251216bytes = 4MiB
  overhead.
• Encouraging implementations to use the shared-memory iterator leads to
  very inefficient emulated drivers as mapping and unmapping are usually
  more expensive than short memcpys and dominate the operation time.

The VMM only really needs features 1, 2 and 9, and it already implements
its own version of region reservations (2) separately. There's also some
helper functions in libsel4utils that implement just 1. and depend on a
vka_t interface that the VMM also already has a copy of.

As for 6. the vmm does need a more efficient copyin/copyout mechanism
that would be somewhat system specific and shouldn't create new mappings
on each access.