Remove dependency of DoorComponent from PryingSystem, add PryableComponent

[Quantum-cross]

About the PR

I want turnstiles to exhibit unique behavior on prying with a tool, and instead of bringing TurnstileComponent into PryingSystem, I saw the light yesterday and am doing the reverse.

I remove common prying datafields from DoorComponent and bring them into a new component PryableComponent. The CanPry datafield is removed and replaced by the existence of PryableComponent on an entity.

All of the PryingSystem events are largely unchanged:

PryingSystem will continue to raise BeforePryEvent to query the entity if prying is allowed or not given the properties of the tool, the state of the user, and the state of the entity.

PryingSystem will continue to raise GetPryTimeModifierEvent to query the entity if the time it takes to pry will be modified due to the state of the user or the state of the entity.

PryingSystem will continue to raise PriedEvent to notify that a pry DoAfter has been completed from a given user.

---

All the weird pry tool flags are now just PryStrength. I can't imagine a tool that can pry a bolted door but not a powered door, so it's just a scale.

The prying door tests have been generalized and every combination is tested.

Why / Balance

Clean up, refactor, allow cleaner integration of planned features in #37350.

Technical details

See About section, not much more complicated than that.

Basically just lets me slap PryableComponent on something like turnstiles and add in unique checks for if it can be pried and unique time modifiers without having to duplicate checks for DoorComponent with TurnstileComponent

Media

none

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

The following properties have been remove from DoorComponent:

• CanPry
• PryingQuality
• PryTime

PryableComponent has been added with PryingQuality and PryTime.

CanPry has been "replaced" with the existence of PryableComponent on an entity.

Prototypes with CanPry: False should have that datafield removed.

PryableComponent has been added to:

• Airlock
• BaseFirelock
• BaseShutter
• BaseWindoor
• HighSecDoor

Abstract prototype BaseShutterPryable is parented from BaseShutter, all shutters are parented to BaseShutterPryable except BlastDoor which shouldn't be pryable.

Handlers of BeforePryEvent should put a fully localized message in the Message field instead of just the loc-string as before.

GetPryTimeModifierEvent requires the base pry time as an argument. Normally this will be the PryTime field of the PryableComponent

PryingComponent no longer has:

• PryPowered
• Force

PryingComponent now has:

• enum PryStrength Strength

Which can take on the values:

• Weak
• Strong
• Powered
• Force

Prototypes with PryingComponent have been changed appropriately.

[EmoGarbage404]

every day ToolSystem creeps closer to death

[Quantum-cross]

Drafting this a moment -- checking something

[Quantum-cross]

@EmoGarbage404 I'm so sorry.... but I added in tons of changes to remove DoorComponent requirements on the BoltSystem and DoorRemoteSystem...

It all ties into how things get pried... so.......

[Quantum-cross]

this is the final extent of the scope creep I promise

[Quantum-cross]

Do tests count as scope creep? I added ~30 tests using a generic prying test function.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[Quantum-cross]

@EmoGarbage404 I've un-scope creeped this, I'll add the work to the bolt system in another PR.
Also poking @ScarKy0 because this is related to the turnstile stuff. I'm about to factor out the construction steps there.

[Quantum-cross]

actually nevermind I'm not labelling this as part of the turnstile improvements :|

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.