Refactor networking logic & Deprecate `PlayerManager`

[Reousa]

This is in preparation for implementing hot-swappable messaging libraries.

Things done:

• Move connection & disconnection logic out of PlayerManager to Server
• Move all messaging logic out of PlayerManager to Server & Client
• Move player tracking out of PlayerManager to Server & add querying logic to an extension class
• Refactor WebSocketService outside of Server, and make it transparent to the rest of the program
• Deprecate & refactor all remaining methods inside PlayerManager to point to their counterparts

---

This PR is included in a series:

1. 634 - Working

2. 638 - Working

   3. #639 - Working

[Reousa]

@Therzok; Extensions served as a temporary placeholder until I removed PlayerManager and conclusions were made over some discord discussions. Admittedly I hadn't considered performance impact yet, given the WIP nature of things, that would've been a later step. 😅

Adjustments made in any case, will rebase #638 after PR acceptance.

By extension & to keep reference, this PR also eliminates dependency on the Locker object, avoiding potential GC triggers in hotpaths from frequent PlayerManager member access.

---

I sadly have no easy way to measure or compare these impacts as of yet, but a mocking of Server and Client to simulate some measurable traffic is something I'm attempting.

With that said, should pooling packets & potentially packet buffers be brought into the scope of this refactor (in a later PR)? I recon that'd have far more impact on easing out the GCs? What do you think?

[Therzok]

Thanks for removing the allocs!

Pooling sounds good, an alternative would be restructuring the generic packet handling to be use where T:struct, IPacket and the JIT will do everything else, but that's probably a bigger refactoring compared pooling.