Windows support about unified

[Liareth]

(comment copied from GitLab, dates are incorrect)

There are still a whole bunch of issues, but (for now), I've lost the desire to fix them.

• ASLR fucks things up. You can bypass this by tweaking with the DllCharacteristics flags in CFF explorer.
• GetString handler segfaults. Debugger shows that the parameter is garbage. Inserting a second string shows the correct data. IDA decompiler things there are two arguments. There should be only one, but I guess the compiler is fucking things up? Either way, this makes the outlook on one-plugin-two-platforms look very grim. We should consider just having "Windows" and "Linux" folders under Plugins, and enforcing that only the core require cross-platform. Calling the original function also breaks, complaining about mis-matched stack, so I'm guessing the Windows compiler optimized this function to pass in the string length and string on the stack, rather than a pointer, or something weird like that.
• Services::ThreadLocalTimeScope asserts when iterating over the thread local string stack. Because of the difference in how DLLs are handled on Windows this wouldn't even work cross-platform anyway, but I don't understand whyyyy it's breaking.

Even if we get past those issues in a reasonable way:

• Windows symbols have no type info.
• This means we have to borrow Linux type info, which, right now, is all manner of fucked up, with ((aligned)) and ((packed) all over the place. This also means that, even if we get real awesome Linux info that isn't IDA exported, we still can't guarantee that the structs will line up correctly.

All-in-all, it's looking like Windows is shaping up to very much be the "wild west" in terms of API. The core works fine and is completely cross-platform, but interfacing with the Windows server is proving difficult.

[Liareth]

(comment copied from GitLab, dates are incorrect)

Going to do a little more work on this. Not windows support directly, but:

• Exclusive hooks go to an exclusive hook handler first. This hook will be automatically decorated with the correct calling convention style for the platform. YES, this is slightly slower (one extra stack frame constructed and dropped), but this is very, very, very minimal.
• Hooks will be requested like this: RequestExclusiveHook<address, convention, ret, params>(fn)
• If convention isn't present, it will default to thiscall.
• Shared handlers will be updated to work with this system also.

This removes the need for the weird macros scattered throughout the code. All you need to do is, RequestExclusiveHook<address, CallingConvention::ThisCall>, and magic happens automatically.

[Liareth]

(comment copied from GitLab, dates are incorrect)

I've done this now, so now all the ugly cross-platform hook landing macros are contained within HooksImpl.hpp.

I'm going to drop this task as being assigned to me for now. I'm still going to code with both platforms in mind but I'm not going to actively develop for Windows until all of the high priority stuff is out of the way (plugins, Arelith-specific stuff, etc).

[Liareth]

Aaand ... we're back in present time. Windows support depends on four things:

1. DWARF parsing for Linux. (@Liareth)
2. PDB parsing for Windows. (@mtijanic)
3. API generator that takes info from both of these and produces a new API. (@Liareth)
4. Fixes to NWNX core to make it work on Windows. (@mtijanic)

See https://github.com/nwnxee/unified-apigen for progress on 1, 2, and 3.

[mtijanic]

Closing this as WNF. We'll support running on Windows via docker or via WSL/WSL2. We won't support the nwserver.exe binary though.

(building on windows is also a possibility, but a separate issue altogether)