Rudimentary Linux support

[Sumandora]

This PR does multiple things:

• It makes the project build on Linux
• It adds support for reading and writing from Linux
• It fixes a few bugs in the architecture code
• It unimplements ppl.h for systems that don't have it.

Those changes all end up giving a basic Linux support for reading and writing.

Protection and Allocation are technically possible, although I haven't implemented them yet, because I feel like the API is kinda lacking here. Under Linux you need to be a debugger to do those things and there may only be one debugger attached to a process at once. And I feel like making regenny be a debugger would not only increase the complexity massively but also be a rough overstep in bounds, because I mostly have GDB attached to the processes that I would like to use regenny on and that would conflict. Perhaps laziness could help here, but that would add even more complexity. I have done it before and just getting those things is very hard because hijacking a thread safely is very complex.

I also think the Lua api is bad, "get_typename" and "get_typename_from_vtable" can be implemented from linux,
get_typename (I assume from a class) is just dereferencing the first pointer to get the vtable and get_typename_from_vtable then just needs to subtract sizeof(void*) from the pointer, read that pointer, then add sizeof(void*) and read the const char* from that address. (RTTI information is stored behind the vtable with GCC, not sure how MSVC does it, haven't looked at it). But since the Process api forces me to provide a function (as it is virtual), the Lua API doesn't need to restrict it to windows. allocate_rwx and protect_rwx being Windows specific is dumb, both can be reimplemented by just calling allocate and protect with RWX permissions. So it should probably be moved to the process and be made virtual so that the implementations can just use their constants.

Apart from that, create_remote_thread is possible, I have in fact done it before, but it is even harder than doing allocation and protection and the amount of state and error handling is insane. I will never implement that. I think derives_from is possible, but I have never looked into GCC RTTI enough to know how.

This is basically it... I also feel like the read_only_allocations thing in the Process is bad, I tried doing something like that, but it just caused some people on low end PCs to run out of memory when using my libraries (speaking of which you can find on my profile, most of the LinuxProcess code just leeches off of my MemoryManager library), because if the process has many libraries then you just end up cloning all of them and that can easily take like a gigabyte... Laziness helps here.

Anyways, I might work more on this, but don't take anything for granted... I also have not tested if this breaks windows support, although I have tried to not break it, but I just have no windows systems running apart from VMs and I don't feel like fighting with Visual Studio, MSVC and Windows-CMake again.

EDIT: I just realized while reading through it one more time, that I may come off as a bit disrespectful, but I'm not, I'm just exhausted from life. I'm sorry.

EDIT2: GCC 15 is also not supported because ThePhD/sol2#1695 is not fixed in a mainline release yet. (GCC 14 is what I tested it with and it appears to work)

[angelfor3v3r]

Hi! Thanks for PR. For now I think it'd be okay to just not implement remote allocation/protection/threads in the Lua API for Linux. I believe it isn't actually used for the main application and you probably don't have to worry about it for now. RTTI would be nice, though.

About sol2, there is a tag here but it didn't get a release pinned for it: https://github.com/ThePhD/sol2/releases/tag/v3.5.0... Maybe we could just use it?