[FEATURE] Add Saving Throw Data Objects

[msprijatelj]

Is your feature request related to a problem? Please describe. Currently, there is no way to easily extract data regarding effects that cause Saves from equipment/reserves/etc., meaning that save effects must be manually interpreted by the user (especially for 3rd-party systems using lancer-data).

Describe the solution you'd like A data object for save effects that can be added to equipment/reserves/etc., with something resembling the following schema:

• "hase": HASE (compcon enum)
• "damage?": Damage[] (compcon object, optional)
• "half?": Boolean (optional, default to "false")
• "description": String (describe effect)
• "status?": ConditionStatus[] (Optional, potential future compcon object, from Conditions/Statuses. Alternatively, this could be included at the "equipment-level" instead of nested within this "save" object; more in the Additional context.)

Describe alternatives you've considered Third-party users of Lancer Data could use a regex/text scanner to detect Saves and their potential effects.

Additional context When Condition/Status is added, it may be better to instead have a catchall parent class that can generally handle "effects caused by equipment/reserves/etc.":

• "active_effects?": ActiveEffect[] (name subject to change, but this could be a parent class that could support Conditions/Statuses, Bonus Damage, Bonuses (or even "maluses" for negative effects), and Resistances/Immunities. Not all these cases are relevant for saves, but an object class like this could be extensible without having to constantly add new fields when they're introduced)

Again though, it may be better to have this kind of object at the base of the JSON tree instead of nested within a "Save" object; then it could be used alongside "on-hit" and "on-crit" effects, too, and the Save would simply exist as a simple object that provides a dice roll prompt and modify damage to be halved, when relevant.

[Eranziel]

I think ideally we might want saves/active-effects supported both at the JSON root and within other fields like on-hit/on-crit. With the intent being that if it is present on the root then it should always happen when the item is used (e.g. grenade systems, grav rifle), and if it's inside of on-hit/on-crit then it only applies in those situations (e.g. chain axe, nail gun).