Port /tg/ move manager, drift and jetpack components.

[warriorstar-orion]

Recreation of #26637 because I can't reopen it due to a force-push or something. Note that /tg/ has moved away from the spacedrift component as of tgstation/tgstation#84869 in favor of more sophisticated newtonian physics in space; my goal here is to unblock all the movement code needed for AI controllers, not to have the latest-and-greatest version of inertial movement.

What Does This PR Do

This PR ports /tg/'s move_manager API, a replacement for use of the native BYOND walk procs. It introduces movement subsystems, which can be used for processing different kinds of movements, adding one for most atom movement and one for items drifting in space.

Two new components are introduced:

• A "space drift" component is introduced which registers atoms with the move manager and handles their continuing movement.
• A jetpack component is introduced, which cleans up jetpack code and coordinates application of space drift via signals depending on if the jetpack is stabilized or not.

The port comprises major pieces from these PRs:

• Adds a movement looping system, replaces inbuild procs and spacedrift with it tgstation/tgstation#62567
• [NO GBP] Jetpack and spacedrift: Fixes and niceties tgstation/tgstation#66628
• Jetpack component & Modsuit module signal clean-up & fixes tgstation/tgstation#76133

move_manager was initially implemented as an SS, but /tg/ appears to be moving away from allowing SSes which don't fire, so it is now a global datum GLOB.move_manager (just for ease of porting, I don't necessarily agree with the move).

Many signals are added.

Something which may be contentious is the glide_size_multiplier, a global which scales glide time based on TD. This may affect the appearance of gliding objects unrelated to movement but will require more testing.

I've had to step through a lot of this code line by line to get it to work, so if you think something needs more documentation, let me know and I should have a good enough understanding to add it.

I would have liked this to be more atomic but I couldn't find a good way to separate the various implementation work without distrusting the result.

Why It's Good For The Game

As the original PR states:

The walk() procs are effectively sleep loops...the MC gets a lot less time then it expects, because it's being consumed by a separate scheduler.

This puts control of movement in userspace and allows for more flexibility. As can be seen, multiple movement subsystems can exist in order to allow for prioritizing or different firing times (in this implementation, we have spacedrift as a separate manager versus everything else).

It's also a pseudo-prerequisite to basic mobs, again attempting to keep the work of porting that as atomic as possible by adding the beneficial dependencies separately.

For other benefits of this approach, see the code that's cleaned up in:

• /mob/living/carbon/human/Process_Spacemove which was coupled with modsuit jetpack behavior;
• not having to set inertia_dir on every item moving around;
• SSspacedrift not having to be a unique implementation but just another SSmovement
• removal of sleep-dependent code as in /obj/item/extinguisher/mini/nozzle/afterattack, /obj/item/reagent_containers/spray, and /obj/effect/decal/cleanable/blood/gibs/proc/streak, among others

How it Works

Cribbing from the original PR again:

We've got a selection of move_loop datums. Each type holds information about what's going to be moved, and how.
So you've got a move_loop type for moving in a direction, two different flavors for moving towards something, one for moving randomly.
Then we have a movement_packet datum. This tracks what move_loops are attached to an object, and which move loop is currently running.
There's a few rules around move loops. Primarily, you can only have one move loop active at once. This is determined by the loops precedence. Secondly, you're only allowed to have one loop per subsystem.

TL;DR, the move_manager gets passed movement instructions attached to atoms in the form of move_loop datums and manages the work of moving things.

This provides mostly drop-in replacements for the `walk()` procs

• Removing something from the loop walk(0) -> GLOB.move_manager.stop_looping()
• Move in a direction walk() -> GLOB.move_manager.move()
• Move towards a thing, taking turf density into accountwalk_to() -> GLOB.move_manager.move_to()
• Move in a thing's direction, ignoring turf density walk_towards() -> GLOB.move_manager.home_onto() and GLOB.move_manager.move_towards_legacy(), check the documentation to see which you like better
• Move away from something, taking turf density into account walk_away() -> GLOB.move_manager.move_away()
• Move to a random place nearby. NOT random walk walk_rand() -> GLOB.move_manager.move_rand() is random walk, GLOB.move_manager.move_to_rand() is walk to a random place

It also provides some signals for handling the continuation and stopping of movement, which could be helpful in the future.

Testing

Testing requires checking the behavior of everything that's had its walk proc usage replaced or which has been moved to the /drift component.

• Verify behavior for simplemob movement.
• Verify throwing things and collision in general.
• Verify behavior for hostile mobs in terms of movement towards/away targets and movement speeds.
• Verify behavior for use of fire extinguishers to propel wheelchairs.
• Verify behavior for spread of gib decals.
• Verify behavior for extinguisher nozzles.
• Verify behavior for spray bottles.
• Verify behavior for infrared beams on assemblies.
• Verify space drift in general.
• Verify coughing up blood in gravity and zero-g.
• Verify blood splatters in gravity and zero-g.
• Verify chances in wheelchair speed based on rider organ injuries/amputations.
• Verify behavior of things being shot through space via disposals, just in case.
• Verify behavior for jetpacks and movement when jetpacks are disabled.
• Verify same behavior for jetpack modsuit modules.
• Verify behavior for throwing objects in space and moving in opposite direction.
• Verify behavior for pushing off turfs and items in zero-g.
• Verify behavior for thrown items bouncing off turfs in zero-g.
• Verify behavior for items scattering from trays used to attack.

This will require TMing especially when it comes to handling lots of moving things at once (e.g. a bunch of stuff drifting in space while someone is trying to fight Bubblegum), though, to be clear, I don't anticipate issues in such scenarios.

Known Issues

• The movement of bots patrolling in zero-g is a little glitchy. This was an upstream issue with this implementation, not an error in the port. I don't plan to fix it because it's a rare circumstance and doesn't break them, and because it might go away with either basic mobs or if I decide to port newtonian physics.

---

Declaration

• I confirm that I either do not require pre-approval for this PR, or I have obtained such approval and have included a screenshot to demonstrate this below.

  ---

Changelog

Despite the relatively invasive nature of this change, this should have no player-facing changes, except for to improve performance. If there's any change or discrepancy in movespeed, throw speed, pull speed, projectiles, etc., it is a regression.

NPFC

[github-actions]

This pull request seems to be stale as there have been no changes in 14 days, please make changes within 7 days or the PR will be closed. If you believe this is a mistake, please inform a development team member on Discord.

[ArcZelf]

The animation when a mob naturally moves (forklift for example) occurs much faster than it did and looks a bit unnatural

gif is at regular speed
When forklift was chasing a mob it looked really janky too, but I unfortunately didn't capture that