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

This reverts commit 218c6705d9.

- [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.

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

Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4532
Reviewed-by: lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>

docs/DesignOverview.md

@@ -1,6 +1,6 @@
 # Design Overview
 
-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.
+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.
 
 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/HosKernel.md

@@ -1,6 +1,4 @@
-# Subsystem: HLE
-
-## HOS Kernel
+# 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.
 
@@ -31,52 +29,3 @@ 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.

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)**
-  - **[Subsystem: HLE](./SubsystemHLE.md)**
+  - **[HOS Kernel](./HosKernel.md)**
   - **[Settings](./Settings.md)**
 
 ## Policies