Introduction of the assembly component and refactoring of pipeframe assemblies

[M-Earthfire]

[Game-Objects][Code-Quality][QoL]

About the PR

This PR introduces /datum/component/assembly. It can be added to an atom to call a proc on the atom whenever another atom that is specified in the component is used on it. Optionally, the same proc can be called when the atom the component is added on is used on that specified component.

The component takes the following arguments in the order given here:

• to_combine_item: this specifies which items will trigger the interaction defined in proc_to_call. This field works with 3 different input types: if a path is given, it checks for this atom path. If a list is given, the component checks against each path within the list. If a tool flag, e.g. TOOL_CUTTING, is given, it checks for the corresponding tool type.
• proc_to_call: This takes a PROC_REF to call when the interaction goes off. Make sure this proc returns TRUE if the assembly was successfull and you don't want the attack to go through
• on_tool_attack: If set to TRUE, the interaction will work if either the component-atom is used on a compatible atom or the compatible atom is used on the atom with the component. Set this to FALSE if you want interactions like tools being used on the atom in question.

To demonstrate the use of this component, all assembly steps of the pipeframe were refactored to use this component. This includes many of the pipeshot steps and the pipebomb assemblies.

Since this PR makes assemblies by hitting cabled frames with igniter-assemblies and vice-versa, the standard pipebomb now requires a timer instead of a timer/igniter-assembly.

This PR fixes #14525

Also, this PR fixes a bug where pipebomb assemblies made out of wired frames didn't carry special items in them, but pipebomb assemblies made out of standard pipebombs did.

Why's this needed?

having to juggle multiple states on assembly process is very cumbersome and requires escalating if-trees. Splitting the steps off by a component enables to just add the new steps and remove the old ones from the item once it has reached a new state. This clear up the code. Also the two-side compability of the component enables to add the component once to the parent that should carry the logic instead of having to copy the assembly step on multiple items.

The refactor of the pipebomb assembly steps serves as an example of it's use. I tried to hold myself back and not make the PR explode too much in scope, since working on pipebomb-, mousetrap- or igniter-assemblies made me scream on multiple occassions. E.g. complete refactor of igniter-assemblies is out of scope of this PR, although the integration of the component helped clean it up.

On the player side, not having to specifically hit the pipebomb with the assemblies helped clear up some confusions and makes construction less of a hassle. The drawback was the necessity to move the standard pipebomb to use a timer.

Changelog

(u)Lord_Earthfire
(+)Pipebomb- and beaker-assemblies should be more intutive to create now.
(+)Standard pipebombs are now created by using a timer instead of a timer/igniter-assembly with a pipebomb frame.

[amylizzle]

if you're already rewriting them, why not make this change?

[M-Earthfire]

I thought about it, but then i would add tons of mapping changes and would need to touch how these are assembled as well. This means i would be touching signaler/igniter/timer and proximity sensor code as well. Overall, i have searched for a point to say "ok, somewhere i got to split it to make the PR not explode too much" and decided to stop at the point where the pipebomb frame interacts with the assemblies. And this PR is already XXL-sized...

But i would definetly tackle the refactor next once this is merged.