Kernel: Properly keep track of mutex lock data in the guest memory. This fixes userland locking/unlocking.

Kernel/Mutex: Propagate thread priority changes to other threads inheriting the priority via mutexes

The implementation is based on reverse engineering of the 3DS's kernel.

A mutex holder's priority will be temporarily boosted to the best priority among any threads that want to acquire any of its held mutexes.
When the holder releases the mutex, it's priority will be boosted to the best priority among the threads that want to acquire any of its remaining held mutexes.

This will be useful when implementing mutex priority inheritance.

Not all syscalls should cause reschedules, this commit attempts to remedy that, however, it still does not cover all cases.

This makes clang-format useful on those.

Also add a bunch of forgotten transitive includes, which otherwise
prevented compilation.

Involves making asserts use printf instead of the log functions (log functions are asynchronous and, as such, the log won't be printed in time)
As such, the log type argument was removed (printf obviously can't use it, and it's made obsolete by the file and line printing)

Also removed some GEKKO cruft.

They're finally unnecessary, and will stop cluttering the application's
handle table.

During normal operation, a thread waiting on an WaitObject and the
object hold mutual references to each other for the duration of the
wait.

If a process is forcefully terminated (The CTR kernel has a SVC to do
this, TerminateProcess, though no equivalent exists for threads.) its
threads would also be stopped and destroyed, leaving dangling pointers
in the WaitObjects.

The solution is to simply have the Thread remove itself from WaitObjects
when it is stopped. The vector of Threads in WaitObject has also been
changed to hold SharedPtrs, just in case. (Better to have a reference
cycle than a crash.)

This should speed up compile times a bit, as well as enable more liberal
use of forward declarations. (Due to SharedPtr not trying to emit the
destructor anymore.)

- ReleaseNextThread->WakeupNextThread
- ReleaseAllWaitingThreads->WakeupAllWaitingThreads.

- Separate wait checking from waiting the current thread
- Resume thread when wait_all=true only if all objects are available at once
- Set output to correct wait object index when there are duplicate handles

This will happen when the mutex is already owned by another thread. Should fix some issues with games being stuck due to waiting threads not being awoken.

This handle manager more closely mirrors the behaviour of the CTR-OS
one. In addition object ref-counts and support for DuplicateHandle have
been added.

Note that support for DuplicateHandle is still experimental, since parts
of the kernel still use Handles internally, which will likely cause
troubles if two different handles to the same object are used to e.g.
wait on a synchronization primitive.