Standardizes & documents Attack Chain. Telekinesis cleanup

[Tsar-Salat]

About The Pull Request

Title. Standardizes the attack chain, documents most procs involved.

I've also implemented stack_traces that will show items that have had the attack chain improperly implemented.

Changes include, but are not limited to:

• Reducing redundant procs, integrating them into their parents if possible (i.e. tool_attack_chain is now part of melee_attack_chain.
• Minor buff to telekinesis allowing it to use most interact() code. This shouldn't be anything significant for balance, its mainly to reduce snowflake code where we are just copying what interact does and putting it in a duplicate proc, but for tk. Gets very excessive quickly.
• Killed about 4 snowflake COMPONENT_NO_x signals, replaced with generic COMPONENT_CANCEL_ATTACK_CHAIN

Ports:

• Unscrambles melee_attack_chain tgstation/tgstation#46391
• Update melee_attack_chain codedocs tgstation/tgstation#49471
• Standardizes attack chain signal returns and fixes a tk bug tgstation/tgstation#54475
• Fixes AI upgrades not being applied correctly tgstation/tgstation#54589
• Fixes the attack chain tgstation/tgstation#54642

Why It's Good For The Game

Beestation has bitten off bits and pieces of these PRs throughout the years, especially with the heretics port. This has just further contributed to the messy chain. With the standardization, we reduce further deviations significantly.

My own personal reasons for adjusting this is for the Retiling Appearance pr, which is seemingly inoperable at the moment, and I have been suspecting a faulty attack_chain is to blame.

Testing Photographs and Procedure

Screenshots&Videos

dreamseeker_QWb73kjkna.1.mp4

Changelog

🆑 rkz, haukeschuemann, Rohesie, Timberpoes, zxaber
refactor: Standardized the entire attack_chain and added stack_traces to detect when & where it fails.
balance: minor buff to telekinesis to use most interact() code. Unlikely to cause major change, just reducing duplicate code where TK would have its own proc for essentially doing the exact same thing
/:cl:

[PowerfulBacon]

This is likely to cause some accidental behavioural changes, is there any way that we can easilly check/test if something is using the old code vs the new method and does that matter?

[Tsar-Salat]

if something is using the old code vs the new method

It's not particularly problematic if something is using the old code for this, as the majority of the work done here is eliminating duplicate signals and standardizing them to use. As the old signals defines don't exist anymore to be send or registered, I don't think that part will cause issues.

What is problematic is if we have attack calls for a specific item or tool or whatever that's ignoring the attack chain. For example tool usage being inside attack procs when they should be in tool_act.

Of course, my natural assumption is that if some item is not following the attack chain or abusing signals, the stack traces of this pr will help identify it rather than introducing further issues.

My real worry for behavioral changes was with telekinesis attacks, but I think I tested that to a reasonable degree and saw no issues.