dispatch_next: Never start dispatching before the kernel is fully initialized

[perlun]

This can sometimes happen, if we have stupid code that does things like this:

mutex_kernel_wait(&tss_tree_mutex); // lock the mutex
mutex_kernel_wait(&tss_tree_mutex); // attempt to lock it again

This will never work, because our mutexing code presumes multi-tasking to be enabled (which is a bit silly, but it's the way it is) and will try to dispatch the next available task if the mutex happens to be locked... This all makes sense if multi-tasking is indeed enabled, since you don't want to wait in the current timeslice more than necessary; it's better to give another process a (smaller) slice to let it run, hopefully reducing overall lock contention.

So, if mutex_kernel_wait is being called like this, dispatch_next should do a DEBUG_HALT, clearly indicating that this likely to be the problem. This will simplify our lives while debugging the code.