Medical Damage - Add alternate armor penetration

[LinkIsGrim]

When merged this pull request will:

• Add alternate damage calculation that takes ammo's penetrative ability into account (aka "caliber"). Includes CBA setting to disable if players prefer previous balance or have custom ammo configs. The idea is that AP ammo should actually make a difference against armored infantry, rather than just cover and vehicles.
• Pass ammo classname to wound handler data (validation for return data remains the same).

Requires #10573.

Armor is converted to RHAe ( pulled from \a3\Data_F\penetration\*.bisurf) based on its scaled value and ignored based on projectile's ability to penetrate material.

Balanced around ACE ammo values. We don't have to worry about 3rd party armor values because of #9216 and an armor soft-cap (at RHAe 110m) implemented in this PR. Overpenetration and angle of incidence are taken into account naturally by using impact damage to calculate impact speed, I actually trust the engine's handling of this more than whatever math we cook up.

IMPORTANT

• If the contribution affects the documentation, please include your changes in this pull request so the documentation will appear on the website.
• Development Guidelines are read, understood and applied.
• Title of this PR uses our standard template Component - Add|Fix|Improve|Change|Make|Remove {changes}.

[LinkIsGrim]

I've realized a way to improve performance on this would be to move it to medical_damage instead, but I don't want to separate damage handling from engine (or add more things to the woundReceived event)

[LinkIsGrim]

I'm happy with this for now. Ready for review.

[johnb432]

This thing might "break" (just wouldn't do anything) in the following scenario:
Third party mod adds a wound handler to bullet, but constructs the return array with [_unit, _allDamages, _typeOfDamage] instead of modifying _this by reference (both are allowed, as per docs). Said wound handler is called before this wound handler and "deletes" _ammo from args.

No idea how likely it's in practice though.

[LinkIsGrim]

I'm aware of the breaking scenario and forgot to mention it. Should be fine to append ammo after each wound handler iteration if necessary if we don't want to break API to make this always work.

[LinkIsGrim]

Could be a setting? /shrug.

[LinkIsGrim]

pushBackUnique will duplicate if someone changes the casing of the ammo string but I see no reason to do that and it shouldn't break anything

[johnb432]

pushBackUnique will duplicate if someone changes the casing of the ammo string but I see no reason to do that and it shouldn't break anything

What worries me in that scenario is if we decide to add more parameters in the future, where it could cause issues.

[LinkIsGrim]

Then I'd say the custom wound handler system is new enough that we can break BWC and help users in updating if that's the case. Still need a better approach though.

[johnb432]

Then I'd say the custom wound handler system is new enough that we can break BWC and help users in updating if that's the case. Still need a better approach though.

If it was added in #8278, then I'd agree it's recent enough, but other opinions are welcome.