Long queries write a 128-bit result value to memory, which consists of a 64 bit query value and a 64 bit timestamp.

In this implementation, only select=Zero of the Crop unit is implemented, this writes the query sequence as a 64 bit value, and a 0u64 value for the timestamp, since we emulate an infinitely fast GPU.

This specific type was hwtested, but more rigorous tests should be performed in the future for the other types.

Kernel/Threads: A thread waking up by timeout from a WaitProcessWideKey may already have an assigned lock owner.

This situation may happen like so:
Thread 1 with low priority calls WaitProcessWideKey with timeout.
Thread 2 with high priority calls WaitProcessWideKey without timeout.
Thread 3 calls SignalProcessWideKey
- Thread 2 acquires the lock and awakens.
- Thread 1 can't acquire the lock and is put to sleep with the lock owner being Thread 2.
Thread 1's timeout expires, with the lock owner still being set to Thread 2.

Also added some proper error handling.

* add some CommandType

* add some hid FunctionInfo

* add some other HID FunctionInfo

* delete non useful comments

* add some InfoType

* correct OpenApplicationProxy cmd number

* add IDisplayController functions

* fix clang-format

* add more system languages

* GetAudioRendererWorkBufferSize impl

Impl of GetAudioRendererWorkBufferSize based on RE, if this can be cleaned up, please contribute!

* Naming conventions

* Removed unneeded placeholder

* lioncache changes

* fixed const

* switched to Common::AlignUp

You can specify a predicate in the fset instruction:

Result = ((Value1 Comp Value2) OP P0) ? 1.0 : 0.0;

We have no clue on what this actually does yet so stubbing it since it's just input only should be fine for now

You can specify three predicates in an fsetp instruction:

P1 = (Value1 Comp Value2) OP P0;
P2 = !(Value1 Comp Value2) OP P0;

Used in Nintendo Labo ToyCon 1&2