kernel/svc: Implement the resource limit svcGetInfo option

Don't try to route PFIFO methods (0-0x40) to the other engines.

Another hold-over from Citra.

Allows a process to register the resource limit as part of its handle
table.

This is a leftover from #1792

[Kernel::CreateThread] Match format specifiers to LOG_TRACE's arguments

svc: Reorganize svcGetInfo, handle more error cases for existing implemented info categories

yuzu/configuration: Minor clean-up related changes

filesystem: De-globalize registered_cache_union

gl_shader_decompiler: Introduce a scoped object and style changes

kernel: Divide Event into ReadableEvent and WritableEvent

service/fsp_srv: Implement CleanDirectoryRecursively

service/audio/audout_u: Amend constructor initialization list order

Fixed crash with SetNpadMode

hle/service: Update function tables for erpt:c and usb's IClientEpSession

Updates the function table for IClientEpSession based off information
provided by SwitchBrew.

Updates the function table according to information provided by
SwitchBrew.

These slots are only ever attached to event handling mechanisms within
the class itself, they're never used externally. Because of this, we can
make the functions private.

This also removes redundant usages of the private access specifier.

Resolves trivial compiler warnings.

The previous code could potentially be a compilation issue waiting to
occur, given we forward declare the type for a std::unique_ptr. If the
complete definition of the forward declared type isn't visible in a
translation unit that the class is used in, then it would fail to
compile.

Defaulting the destructor in a cpp file ensures the std::unique_ptr's
destructor is only invoked where its complete type is known.

fixed crash due to handheld

The kernel uses the handle table of the current process to retrieve the
process that should be used to retrieve certain information. To someone
not familiar with the kernel, this might raise the question of "Ok,
sounds nice, but doesn't this make it impossible to retrieve information
about the current process?".

No, it doesn't, because HandleTable instances in the kernel have the
notion of a "pseudo-handle", where certain values allow the kernel to
lookup objects outside of a given handle table. Currently, there's only
a pseudo-handle for the current process (0xFFFF8001) and a pseudo-handle
for the current thread (0xFFFF8000), so to retrieve the current process,
one would just pass 0xFFFF8001 into svcGetInfo.

The lookup itself in the handle table would be something like:

template <typename T>
T* Lookup(Handle handle) {
    if (handle == PSEUDO_HANDLE_CURRENT_PROCESS) {
        return CurrentProcess();
    }

    if (handle == PSUEDO_HANDLE_CURRENT_THREAD) {
        return CurrentThread();
    }

    return static_cast<T*>(&objects[handle]);
}

which, as is shown, allows accessing the current process or current
thread, even if those two objects aren't actually within the HandleTable
instance.

Our implementation of svcGetInfo was slightly incorrect in that we
weren't doing proper error checking everywhere. Instead, reorganize it
to be similar to how the kernel seems to do it.

Orders the constructor initializer list the same way the members of the
class are declared. Prevents -Wreorder warnings

gl_rasterizer: Enable clip distances when set in register and in shader

gl_shader_manager: Update pipeline when programs have changed

video_core: Minor style changes

 gl_rasterizer_cache: Fix several surface copy issues.

We can just return a new instance of this when it's requested. This only
ever holds pointers to the existing registed caches, so it's not a large
object. Plus, this also gets rid of the need to keep around a separate
member function just to properly clear out the union.

Gets rid of one of five globals in the filesystem code.

UI: Remove border from Game List

Services/VI: Dereferencing an uninitialized std::optional is undefined behavior.

A non-existent parameter was left in some formatting calls (the logging
macro for which only does anything meaningful on debug builds)

Ensures that read only indeed means read only.

This is the same behavior-wise as DeleteDirectoryRecursively, with the
only difference being that it doesn't delete the top level directory in
the hierarchy, so given:

root_dir/
  - some_dir/
    - File.txt
  - OtherFile.txt

The end result is just:

root_dir/

Assert that it is not empty before using it in the DequeueBuffer wait callback.

 service/set: Implement MakeLanguageCode

This code was around prior to the introduction of PushEnum, so convert
it over so we don't need to cast here.