TODO

* multi-core
	* thanks to the recent re-architecturing this should be implementable fairly easily
	* does this work without supporting multiple VCPUs per module?
		* since in the current hierarchical scheduling approach VCPUThreads are essentially checkpointed threads
		  that start from the checkpoint each time they are invoked, running a single VCPUThread multiple times in parallel from multiple core seems conceptually sound
		* scheduling data is protected against concurrent access, thread data access would need the same approach
		* (currently locking the mutex of the running VCPUThread would fail and trigger an assert)
		* the CPU analogy breaks down though
	* schedsi.Scheduler thread queues need to be fixed
		* a thread might still be executing while another scheduler-thread moves it around the queues
		* prev_run_time tracking needs to be fixed
* support multiple VCPUs per module
	* easy: sort threads to VCPUs on creation
		* could also use run-time balancing
	* advanced: mutli-core aware schedulers
* run-time balancing of threads between schedulers
	* schedulers need support to remove threads from their queue
		* the schedulers should probably decide themselves which thread to pass on
	* need a dedicated thread to do this balancing
		* or integrate into scheduler
* external interrupts
	* also thanks to the recent re-architecturing this should be implementable fairly easily
	* basically we just want to jump back to the kernel to "handle" some interrupts
* simulate message-passing
	* synchronous message-passing should be the most interesting thing here, since it puts threads to sleep until the message round-tripped back and wakes it again
* timer coalescing
	* allow specifying a timer resolution/tolerance to elapse earlier and/or sooner
	* this can reduce context switches when timers in a chain that is resumed would elapse very soon, at the cost of precision