epic: Profiling

We want to have robust profiling support for both the kernel and guest code. Implementing support will look rather different for either one. ## Data Sources I want any profiling to be _holistic_ i.e. measuring the entire system, kernel and guest code. This is because I believe it is a much more helpful data source AND because - being a JIT runtime - the kernel code is much more relevant to overall system performance. This means unifying events from quite different data sources, we currently already make extensive use of `tracing` in the kernel so I think (?) it would make sense to use that as the unifying layer if possible. - hardware events - cpu cycles (the number of CPU cycles that happened) - instructions (the number of instructions retired) - cache events (references, hits, misses) - branch events (total instructions, hits, misses) - kernel events - page faults - page evictions - task lifecycle events (creation, beginning execution, pausing execution, resuming execution, termination) - cpu migrations (i.e. scheduler steals. When a task migrates to a different CPU) - compilation stats (spans for individual functions, for a module, for a component, spans for stages, parsing, translating, compiling) - instantiation stats (i.e. spans for instance & instance data allocation, for data initialization, etc) - instantiation cache stats ((if we add caching for instance data) cache hits, misses, evictions) and likely much more ## Open Questions 1. Are events (and spans) the only data source format we need? A number of data points (e.g. tasks in a system) would best be visualized by a counter. Emitting events for task start and stop obviously produces more data that can be filtered down. Maybe only emitting events and spans and aggregating is the best approach? 2. How would this data be exposed? At the moment the kernel tracing subsystem will just print all _events_ (not traces) to the UART unbuffered. This is obviously not a great long term solution. Ideally we put all events into a ringbuffer I guess? Do we expose the [`tracing::Subscriber`](https://docs.rs/tracing/latest/tracing/trait.Subscriber.html) trait as an interface to Wasm for userspace tracing?