Core: Rewrite message to IPC

[zach2good]

I affirm:

• I understand that if I do not agree to the following points by completing the checkboxes my PR will be ignored.
• I understand I should leave resolving conversations to the LandSandBoat team so that reviewers won't miss what was said.
• I have read and understood the Contributing Guide and the Code of Conduct.
• I have tested my code and the things my code has changed since the last commit in the PR and will test after any later commits.

What does this pull request do?

No more of this:

        const uint32 size      = sizeof(uint32) + sizeof(uint32) + sizeof(uint32) + sizeof(uint8) + 256;
        char         buf[size] = {};
        std::memset(&buf[0], 0, size);

        ref<uint32>(buf, 0) = charId;
        ref<int32>(buf, 4)  = value;
        ref<uint32>(buf, 8) = expiry;
        ref<uint8>(buf, 12) = static_cast<uint8>(std::min<size_t>(varName.size(), 255));
        std::memcpy(buf + 13, varName.c_str(), varName.size());

        message::send(MSG_CHARVAR_UPDATE, buf, size, nullptr);

Only this:

        message::send(ipc::CharVarUpdate{
            .charId  = charId,
            .varName = varName,
            .value   = value,
            .expiry  = expiry,
        });

If IPC is easy, it's easier to build things on top of it.

TODO & Testing

• Rename/remove old system and calls to it
• Go through and finish all the TODOs in my code that need addressing before merge (some are reminders for the far future)
• Add own debug logging category

Ensure all the IPC message types are implemented with what they need, and do what they need to:

• M2W -> EmptyStruct
• M2W -> CharLogin
• M2W -> CharVarUpdate
• M2W -> ChatMessageTell
• M2W -> ChatMessageParty
• M2W -> ChatMessageAlliance
• M2W -> ChatMessageLinkshell
• M2W -> ChatMessageUnity
• M2W -> ChatMessageYell
• M2W -> ChatMessageServerMessage
• M2W -> PartyInvite
• M2W -> PartyInviteResponse
• M2W -> PartyReload
• M2W -> PartyDisband
• M2W -> AllianceReload
• M2W -> AllianceDissolve
• M2W -> PlayerKick
• M2W -> MessageStandard
• M2W -> MessageSystem
• M2W -> LinkshellRankChange
• M2W -> LinkshellRemove
• M2W -> LinkshellSetMessage
• M2W -> LuaFunction
• M2W -> KillSession
• M2W -> RegionalEvent
• M2W -> GMSendToZone
• M2W -> GMSendToEntity
• M2W -> RPCSend
• M2W -> RPCRecv

===

• W2M -> EmptyStruct
• W2M -> CharLogin
• W2M -> CharVarUpdate
• W2M -> ChatMessageTell
• W2M -> ChatMessageParty
• W2M -> ChatMessageAlliance
• W2M -> ChatMessageLinkshell
• W2M -> ChatMessageUnity
• W2M -> ChatMessageYell
• W2M -> ChatMessageServerMessage
• W2M -> PartyInvite
• W2M -> PartyInviteResponse
• W2M -> PartyReload
• W2M -> PartyDisband
• W2M -> AllianceReload
• W2M -> AllianceDissolve
• W2M -> PlayerKick
• W2M -> MessageStandard
• W2M -> MessageSystem
• W2M -> LinkshellRankChange
• W2M -> LinkshellRemove
• W2M -> LinkshellSetMessage
• W2M -> LuaFunction
• W2M -> KillSession
• W2M -> RegionalEvent
• W2M -> GMSendToZone
• W2M -> GMSendToEntity
• W2M -> RPCSend
• W2M -> RPCRecv

===

• World server does the exact same redirects as it did before
• Rewrite ConquestSystem to not manually build it's own structs for transport
• Establish a good pattern for RegionalEvent and ConquestSystem for future/current use
• Test and ensure every workflow works, and does what it did before
• Ensure that the ZMQ sockets are blocking in line with their defined timeouts, and that decreasing them from 500 to 200 doesn't spike up the OS reported resource usage, etc.
• Update the docs around the build, the codegen, etc.
• Put in a stub PartySystem in World Server and hook up all the party-related messages to it.
• Look into (but maybe don't implement yet) more caching in the world server.
• Look into (but maybe dont' implement yet) more caching in the map server ipc client, and remove db queries there if possible

===

• Test on Linux (single process)
• Test on Linux (multi process)
• Test on Windows (single process)
• Test on Windows (multi process)
• Get some performance metrics
• Make sure Tracy is happy with everything

===

• Clean up commits
• Does this need an ADL to describe what/why, etc?
• When you add new structs to the generate script, how user-friendly are the resulting error messages?
• Need to find a clean way to mark "this isn't implemented here" for certain message types, that advertises that this is just here because of the system and we shouldn't be getting traffic here.

===

In future PRs:

• How can I extend this into the module system, so that modules can define their own additions, redirects, and responses in the IPC?