core: Party rewrite

[sruon]

I affirm:

• [x] I understand that if I do not agree to the following points by completing the checkboxes my PR will be ignored.
• [x] I understand I should leave resolving conversations to the LandSandBoat team so that reviewers won't miss what was said.
• [x] I have read and understood the Contributing Guide and the Code of Conduct.
• [x] 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?

#7181

I'm gonna take more time to expand later but the elevator pitch:

World:

• Makes the World server authoritative on party management, through WorldParty stored in a PartySystem
• World Server publishes complete updates to each relevant Map server on changes

Map:

• Map Server stores read-only counterparts of the WorldParty in CCharParty (stored in a PartyContainer)
• CCharParty deals with CCharEntity directly and has the full set of helpers to mirror what used to be CParty but it can also be cast to PartyBase when it needs to deal with the raw PartyMember
• Map Server merely forwards player requests through IPC to the World Server. CCharParty is built in a way that forbids updates that are not from the IPC system.
• All party lua bindings map directly to CCharParty instead of being stuffed in CLuaBase
• Mob parties are their own thing now, since they only need a very small subset of the logic for linking and targeting purposes.

What's missing:

• Missing bits of logic here and there. Missing lots of validation.
• Naming conventions are all over the place
• Need to build an expanded set of test cases (by retesting every interaction on retail, incl. packet injection)
• Building Alliances on top of it
• Finishing MobParty

What I'm still trying to figure out:

• Should the trust summons go through the system. Meaning they would not spawn until the world process has acknowledged and validated the request. Currently it's a bit disjointed as the map server spawns them directly and then tells the party system about it.
• While I appreciate the communication of intent with std::optionalstd::reference_wrapper>, it makes using the values incredibly more verbose than a regular pointer.
• If we really need the database to store anything about the parties.
  • The only place it's useful right now is the Search server but I'm thinking we could just extend the ZMQ pattern and have it receive certain events.
• I have been toying with custom alpaca serializers to stream some classes directly but I dislike the way it's done.

Steps to test these changes