[DO NOT MERGE] Personal SOI Accountability

[Fate-JH]

Quick and simple
I have changed the way players are assigned to individual SOI regions and would like to have this tested on a greater scale. Relevant code is found in the file InteractWithSOI.scala which is implemented in Player.scala.

Procedure
This is merely a request for a stress test. Just having many player characters join the game and exist somewhere in the game world should be enough. Some of you do this "multi-box" testing far more efficiently than I ever could and I wish to leverage that. The test target is a player character who is unmounted. No player character has to do anything specific.

Caution
This is not merge-ready code. Most of what I would be replacing is just commented or skipped around. A lot of conditions are not handled. Mounting in vehicle or turret is unhandled. Zone transfers may probably work but are untested for proper behavior.

Expanded
Currently, any facility with a significant sphere of influence is assigned players who occupy that sphere of influence from a zone directive called the SphereOfInfluenceActor. The name is not very inventive, but that's not an issue. I consider the SOI an aspect of the environment and thus a demonstration of the player interacting with the zone's blockmap. Even the process consider this a blockmap determination from the perspective of the facilities. For this purpose, I would give each player the responsibility of reporting their own involvement in a facility's sphere of influence and remove from the zone a top-down policy of assigning it as well as a requirement to manipulate the system's active state. To the latter point, the fully active system for all zones was determined to be a significant drag on processing and latency back when it was first released such that a shoehorned moniker "player management systems" was granted to it and a power toggle was employed. It would only be initiated when the first player joins or ceased when the last player leaves, respectively. Actual implementation of the system was a timed process that interupted other actions and demanded it be given treatment.

The rewritten proposed mechanic is a ZoneInteraction so it no longer requires the power switch; and, the activity is tagged onto the standard PlanetsideStateUpstreamMessage message responsibility rather than interjecting a whole new game tick operation; but, due to that it operates per player and is still given at least a shallow probe once every PSUM tick, the over-all processing drag concern of the original system might become a renewed concern. That is why I am requesting the performance test.

I had been toying with this idea for a while. I have some potential uses for it, if it pans out.