[hle] constexpr handler dispatch maps, introduce version gating (#4480)

This PR primarily focuses on upbringing constexpr maps for handlers.

Each time an HLE object of a service is construed, it registers it's own handlers, over and over.
Regardless of whetever it needs them at the moment or not.
Additionally we don't require to keep track of different function pointers amongst each object.
This can be done by overriding the given function instead, as opposed to having a separate
hash map for every given object.

In other words: Remove handlers (and handlers_tipc) map for every instance
then read from a static defined per-class.

- [x] Migrate all HLE functions to new `frozen::map` constexpr time finder
- [ ] Measure if this approach actually makes better codegen

Optional:
- [x] Properly gate all functions (that have versions commented next to them)
- [x] Maybe store `HandlerFnP<>` and `const char*` separately, version gating can go in a different map as well

Information such as name can be used on debug builds, but doesn't particularly help on release as one can consult an external reference (or have an annotated IPC map)

Signed-off-by: lizzie <lizzie@eden-emu.dev>

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.

-------------------

Co-authored-by: Maufeat <sahyno1996@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4480
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>

docs/DesignOverview.md

@@ -1,6 +1,6 @@
 # Design Overview
 
-Modern game consoles require heavy power to be emulated appropriately. This is why the emulator uses an approach known as HLE (High-Level-Emulation), in a nutshell: Instead of accurately emulating every subsystem that forms part of a component, emulate the resulting visible I/O interface instead.
+Modern game consoles require heavy power to emulate. This is why the emulator uses an approach known as HLE (High-Level-Emulation), in a nutshell: Instead of accurately emulating every subsystem that forms part of a component, emulate the resulting visible output of said interface instead.
 
 For example, take a disk write, instead of emulating a proper SD card we instead use the C++ standard library for I/O. Additionally we use the abstractions provided by the `fs` service to "lie" to programs about certain SD card properties. Notably this includes making up sizes for the fake SD card, giving "realistic" values or expected outputs for a given card, and so on. And instead of writing to an actual SD card, the emulator simply writes to a file.
 

docs/README.md

@@ -21,7 +21,7 @@ This contains documentation created by developers, build instructions, guideline
 - Subsystems:
   - **[Design Overview](./DesignOverview.md)**
   - **[Dynarmic](./dynarmic/README.md)**
-  - **[HOS Kernel](./HosKernel.md)**
+  - **[Subsystem: HLE](./SubsystemHLE.md)**
   - **[Settings](./Settings.md)**
 
 ## Policies

docs/SubsystemHLE.md

@@ -1,4 +1,6 @@
-# HOS Kernel
+# Subsystem: HLE
+
+## HOS Kernel
 
 In brief, the HOS kernel is a microkernel, all services and programs run in userspace, the primary way to do communication between these is via `HIPC` (not covered here); otherwise most of the primitives reside in the forms of syscalls invoked via `svc #imm`. The kernel supports both 32-bit and 64-bit programs, and has the capacity to use 32, 36 and 39 bits of address space for spawned processes. Most of the networking stack is based off FreeBSD's network stack.
 
@@ -29,3 +31,52 @@ Every process keeps it's own tracking of the following structures:
 The emulator willingly restricts itself to only use 4 threads (to emulate 4 cores), this is because most existing applications do not benefit greatly from the added core count, and in fact can be detrimental due to extra contention. This translates equitatively to about 4 `ArmInterface` slots for each process, these are then redirected to whatever is the last `pc` of the last thread running on the core is meant to be; proceed to run it, then when returning (due to halt or interruption), proceed to reschedule the thread.
 
 The scheduler as-is isn't 100% faithful to the original (for example the original is cooperative and not preemptive), and has great timing variance (especially due to the fact the emulator can run in systems with wildly different timings).
+
+## Services
+
+Consult [SwitchBrew](https://switchbrew.org/) for per-service methods, and implementation details.
+
+All services are instatiated implicitly using `ServiceFramework`. To register a new interface or service, you can inherit from said class, providing additionally a template parameter that references `Self`, for example:
+
+```c++
+// Follows as:
+// class MyInterface [final] : public ServiceFramework<MyInterface> { ... };
+// [final] is optional, but should be used whenever there is no intention of this class itself being inherited.
+class IFloatingRegistrationRequest final : public ServiceFramework<IFloatingRegistrationRequest> {
+public:
+    // ctor, you can pass extra parameters here (if so required)
+    explicit IFloatingRegistrationRequest(Core::System& system_)
+        : ServiceFramework{system_, "IFloatingRegistrationRequest"}
+    {}
+
+    // Must be placed after all methods are defined (or declared).
+    // Define here your functions and methods, please order them.
+    // Use FindRequestTipc for TIPC handlers.
+    static constexpr auto functions = CreateStaticMap(
+        FunctionInfo{0, nullptr, "GetSessionId"},
+        FunctionInfo{12, nullptr, "GetAccountId"},
+        FunctionInfo{13, nullptr, "GetLinkedNintendoAccountId"},
+        FunctionInfo{14, nullptr, "GetNickname"},
+        FunctionInfo{15, nullptr, "GetProfileImage"},
+        FunctionInfo{16, nullptr, "GetProfileLargeImage", MakeVersionGate({18,0,0})},
+        FunctionInfo{21, nullptr, "LoadIdTokenCache"},
+        FunctionInfo{100, nullptr, "RegisterUser"},
+        FunctionInfo{101, nullptr, "RegisterUserWithUid"},
+        FunctionInfo{102, nullptr, "RegisterNetworkServiceAccountAsync", MakeVersionGate({4,0,0})},
+        FunctionInfo{103, nullptr, "RegisterNetworkServiceAccountWithUidAsync", MakeVersionGate({4,0,0})},
+        FunctionInfo{110, nullptr, "SetSystemProgramIdentification"},
+        FunctionInfo{111, nullptr, "EnsureIdTokenCacheAsync"}
+    );
+    std::optional<FunctionInfoBase> FindRequest(u32 key) override {
+        return HandlerTableGenerateWithFind(key, functions);
+    }
+};
+```
+
+Try to keep service structures local, that is, don't place them on header files if they're only going to be used by a specific service.
+
+In each `.cpp` file that uses `D<...>/C<...>` CMIF wrapper helpers, remember to include the corresponding instancer, so you don't face linker errors:
+```c++
+#include "core/hle/service/cmif_serialization.h"
+```
+This will properly instatiate the corresponding wrappers and decompose the provided arguments in the wiring order.