Adds setter for anchored. Cleans up a lot of anchored, density, and update_icon implementations

[Tsar-Salat]

Ports:

• Makes all anchored changes use setAnchored(), COMSIG_MOVABLE_SETANCHORED now only sent if an AM's anchored var has changed for more reliable usage. tgstation/tgstation#52254

About The Pull Request

Basically converts a bunch of anchored = T/F to set_anchored(T/F), which is a direct upgrade.

Cleans up a shitton of anchored implementations. I also cleaned up a few density and icon calls because they were adjacent.

The largest cleanup occured in how library shelves anchored. It sucks a lot less

Why It's Good For The Game

I looked at literally every implementation of anchored =

This is going to solve a lot of issues with this stupid var.

Basically, creating a setter proc as opposed to just setting value on the var directly has the benefit of allowing us to append behavior whenever we call it.
In this case and the prior #8689, we are attaching a signal so it fires whenever the anchored value successfully changes.

With set_anchored now defined at the atom-level, we can move behavior that was before on snowflake procs, onto it.

For example, machines that are dependent on being anchored to function (Satellites, Pacman, etc.), this is useful, mostly for code cleanliness.

For the fix part of this pr, its because of how poorly bookcases handle states, akin to the mess that was #9989

Testing Photographs and Procedure

Screenshots&Videos

dreamseeker_Uyz8NHfp1S.mp4

Changelog

🆑 RKz, ShizCalev
refactor: Converted everything to use setAnchored() as opposed to setting the anchored var directly. This means that COMSIG_MOVABLE_SETANCHORED can now actually be used reliably to track if an object's anchored var has changed.
fix: The refactor also means that varediting the anchored var will now properly update most items' other states that rely on it being set a certain way.
fix: Fixed bookcases having the incorrect icon when they're unanchored.
fix: Fixed bookcases not automatically picking up spellbooks / storage books when made/spawned.
fix: Fixed bookcases not dropping spellbooks / storage books when deconstructed.
/:cl:

[github-actions]

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

[Tsar-Salat]

fug forgot testing evidence

[github-actions]

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

[github-actions]

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

[github-actions]

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

[Tsar-Salat]

Is this still a draft?

Its ready, just didnt update for when dragon reverted his machine changes

[github-actions]

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

[Rukofamicom]

This PR needs a better explanation of how it improves the game than:

This is going to solve a lot of issues with this stupid var.

Try to list the "lot of issues" this solves.
The parent PR from TG does no better job of explaining this.

[Tsar-Salat]

Try to list the "lot of issues" this solves.

I thought I was thorough in the changelog. If you'd like to me elaborate specifically on how this works, sure.

Basically, creating a setter proc as opposed to just setting value on the var directly has the benefit of allowing us to append behavior whenever we call it.
In this case and the prior #8689, we are attaching a signal so it fires whenever the anchored value successfully changes.

With set_anchored now defined at the atom-level, we can move behavior that was before on snowflake procs, onto it.

For example, machines that are dependent on being anchored to function (Satellites, Pacman, etc.), this is useful, mostly for code cleanliness.

For the fix part of this pr, its because of how poorly bookcases handle states, akin to the mess that was #9989

[Tsar-Salat]

I made this PR in April, I dont know why I didnt show testing evidence for satellites and booksshelves. Probably because of the long draft period.

Ill do that when I have free time after my exams

[Rukofamicom]

I don't believe additional testing evidence is necessary in this case, and thank you for the detailed explanation.

Several months old and appears to be resolved.