Force generator math updates

[SuperStucco]

This updates the calculations that convert the XML availability data into a weighted random selection table. Some of it is fine tuning, like ensuring the introduction year adjustments are working as intended, plus readability improvements. The biggest changes:

• converting from availability to weight uses a 2^(av/2) calculation which returns a double for odd numbers. Previously this was accumulated as a truncated int, which is now a double all the way through until being normalized.
• total weights of all units now add up to 100.0 up to the point the values are 'normalized' to integers for final use. This makes it easier to check values during debugging e.g. a specific model with a weight of 2.5 will be selected 2.5 percent of the time. This will occasionally be a bit off when other input data such as mixed weight class compensation or C/SL/O compensation is 'off' but is good for normal operation.
• full accounting for various weight influences, including role adjustments, on model weight totals
• some loop optimization on chassis and model filtering
• rebuild of the Clan/Star League/Omni ratio compensation system. This takes the raw availability data and attempts to adjust it to fit the pre-defined percentage values. New calculations are more explicit in what they are doing, and include a number of filters and safeguards, like only processing certain types of units. Also writes some log entries when the data doesn't fit expectations.
• better handling of IS base mixed tech units
• fixes a couple of typos in Clan Jade Falcon C/SL/O ratings found during testing; can't have 90 percent Omni units when only 54 percent of the units are Clan since the only Omni units must be Clan base

There's a few outstanding issues I've identified as requiring improvement but deferring to a later PR:

• non-linear availability is only partially implemented and currently non-functional. Properly fleshed out, this will allow multiple discrete availability settings for different equipment ratings e.g. FS!A:8,FS!B:5,FS!C:2,FS:1 would be used to indicate availability 8 for rating A, 5 for B, 2 for C, and 1 for everything else.
• better handling of C/SL/O ratios is needed for aerospace fighters and vehicles. Currently these automatically default back to the Mek values which are not always appropriate. For example, late Clan Invasion era major IS factions have about a 10% Clan value in the Mek rating and no specific pctClan XML element for vehicles. So it tries to balance the weights of vehicles around 10% Clan but as there are no Clan vehicles made available to the IS factions there is nothing to adjust. Aerospace fighters are a similar situation. This might be fixed with added data, but there might be some code improvements to look at as well.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 28.97%. Comparing base (2e45dc0) to head (def6259).
Report is 5 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #6244      +/-   ##
============================================
- Coverage     28.99%   28.97%   -0.03%     
- Complexity    13982    13983       +1     
============================================
  Files          2652     2652              
  Lines        268296   268509     +213     
  Branches      47764    47828      +64     
============================================
+ Hits          77799    77802       +3     
- Misses       186615   186824     +209     
- Partials       3882     3883       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SJuliez]

Are base Clan units with IS equipment not covered by this?

[SuperStucco]

There are comparatively few Clan units with IS tech, and with far lower impact, so it doesn't cover those. This is primarily to hit the early Clan/Clan Invasion refits of classis IS designs with Clan-tech weapons like the Shadow Hawk C, Rifleman C, Warhammer C, and so on.

Maybe change the method name to isMixedISTech, just to be explicit?

[SJuliez]

Is it necessary to perform this array wrap? It feels like this should work without it.

[SuperStucco]

Indeed it does - now updated