Combat tests - fluent fights and highly performant updates go hand in hand

The combat-tests were great, and focused on improving not only the feeling and responsiveness of the units, but also ironed out bugs and fully reworked a key element: the unit sensor system.

Questions (and answers) from the play-test

- Is the combat engaging and fun? - Definitely engaging! The cover mechanics work, strategy, positioning is key to win... However, we want to improve on the active abilities, add more variation here.

- Is it fluent, stable and properly working? - Debugged lot's of hiccups, improved responsiveness and ultimately the combat of ~25v25 units ran well (with old sensors, see below for the good news).

- Is it performant? With many units it was okay on a mid-tier PC, but that was not enough. We identified a 3rd party (unit) sensor system as a major slow-down, despite only using sensor updates sparingly. Better optimize it now, as it is vital in so many parts of the game.

New unit sensors, what's behind that?

Took some days and headaches, but we replaced the 3rd party sensor solution with a custom solution, incl. all the modern tech bells and whistles, using multi-threading, Unity's Jobs system and Burst compiler, reaching a really impressive state of the art sensor system, great in scalability. Some interesting numbers on that:

- Old sensors (3rd party): 500 sensors, polling just every 1s, caused frame rate spikes, sluggish unit responsiveness and that was already despite own optimizations on that sensor.

- New sensors (own development, fully tailored to our specific needs): 500 sensors, it barely appears in the analysis tools due to highly efficient code and low CPU load, despite real-time per-frame updates!

- New sensors: for fun, we setup 20.000 (!) sensors, sensors start to appear in the analysis tools.

- For fun, part 2: cranked up the number to 40.000 sensors and still had a stable ~60 FPS rate, in Editor mode (!), thus in build will be higher. (although got to admit, that the speed of polling is throttled then to 0.5s, as we reach limitations on how fast data can be transferred within the engine - the calculations itself still stay within astonishing 100FPS)

We won't have 40.000 units with sensors concurrently on the field, but knowing, that the sensors won't be a bottleneck is a relief. In fact, this allows us to have multiple sensors per unit, giving them different behavior options depending on which sensor got activated: front (view) sensor? close-range sensor? sensor from behind?