We should just straight up not be processing turfs if the adjacent turf
isn't correctly setup

It used to be on a seperate subsystem with a second wait with the idea
of reducing the cost of explosions, but since they're instant now
there's no reason to not just have it on SSair. Gets rid of my excuse
for process_cell runtimes too

<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->

## About The Pull Request

I done fucked it lads. Space turfs are never initialized, so asserting
all shareable turfs have a cycle below 0 is not safe. instead we'll use
-infinity. if that ever breaks I'll eat my shoe
Closes #73961

This reverts commit 4979288.

This reverts commit d21e4ab.

This reverts commit dabd6e3.

 into LINDA-FINALLY!!!!!!!!

…ficantly by 33% (#74233)

It is faster to operate on a gas list, especially if cached, then it is
to operate on a datum.
Doing this cause I'm seeing cost in merge() post #74230

Hits on a few other important places too. self_breakdown and such. Worth
it IMO

Could in theory go further by caching the global list. I'm tempted I
admit but it needs profiling first and it's late

EDIT: I have not slept, and have gone tooo far

[Micros /gas_mixture/copy and copy_from, adds a new proc to handle
copying with a ratio,
copy_from_ratio](tgstation/tgstation@91da000)

[91da000](tgstation/tgstation@91da000)

The ADD_GAS sidestep saves us 0.1 seconds of init (used to at least.
Ensuring we don't break archive is gonna have a cost. I don't want to
profile this so I'll estimate maybe 0.05 seconds). The faster version of
copy_from is just well, better, and helps to avoid stupid

[Optimizes pipeline
processing](tgstation/tgstation@bf5a2d2)

[bf5a2d2](tgstation/tgstation@bf5a2d2)

I haven't slept in 36 hours. Have some atmos optimizations

Pipelines now keep track of components that require custom
reconciliation as a seperate list.
This avoids the overhead of filtering all connected atmos machinery.

Rather then relying on |= to avoid duplicate gas_mixtures, we instead
use a cycle var stored on the mix itself, which is compared with a
static unique id from reconcile_air()
This fully prevents double processing of gas, and should (hopefully)
prevent stupid dupe issues in future

Rather then summing volume on the gas mixture itself, we sum it in a
local var.
This avoids datum var accesses, and saves a slight bit of time

Instead of running THERMAL_ENERGY() (and thus heat_capacity(), which
iterates all gases in the mix AGAIN) when processing gas, we instead
just hook into the existing heat capacity calculation done inside the
giver gases loop
This saves a significant amount of time, somewhere around 30% of the
proc, I think?

This doesn't tackle the big headache here, which is the copy_from loop
at the base of the proc.

I think the solution is to convert pipelines to a sort of polling model.
Atmos components don't "own" their mix, they instead have to request a
copy of it from the pipeline datum.
This would work based off a mutually agreed upon volume amount for that
component in that process cycle.

We'd use an archived system to figure out what gases to give to
components, while removing from the real MOLES list.

We could then push gas consumption requests to the pipeline, which would
handle them, alongside volume changes, on the next process.

Not sure how I'd handle connected pipelines... Merging post reconcile
maybe?
This is a problem for tomorrow though, I need to go to bed.

Saves about 30% of pipeline costs.
Profiles taken on kilo, until each reconcile_air hits 5000 calls

[old.txt](https://github.com/tgstation/tgstation/files/11075118/Profile.results.total.time.txt)

[new.txt](https://github.com/tgstation/tgstation/files/11075133/profiler.txt)

…Station-Hornet into LINDA-FINALLY!!!!!!!!

 into LINDA-FINALLY!!!!!!!!

…ion-Hornet into Linda-Recoup

Fixed your tanks!

…2 AM

I admit I rushed it; didn't test it then went back and saw a flaw at 2 AM

…ion-Hornet into Linda-Recoup