Improves client.eye system + advanced camera now accepts observing of mobs

[EvilDragonfiend]

About The Pull Request

Two improvements in this PR

• Improves client.eye system
  • This correctly tracks how a client's eye is changed from what to what.
  • new variable /atom/var/list/eye_users
  • new variable /client/var/datum/weakref/eye_weakref
  • Very minor referencing Multiz Rework: Human Suffering Edition (Contains PLANE CUBE) tgstation/tgstation#69115
• advanced camera now accepts observing of mobs
  • Only camera_advanced.dm. Exclude to review this if you

These actually can go separately, but this is specifically merged to track new atom variable list/eye_users in general system

• client/list/images is too excessive if you don't care z level of images, thus the PR ([PORT] Follows up TG's atom_hud system #10897) has made client images are only visible to you when you're at the same z.
  But, meanwhile, this doesn't respect your current eye. If you see things through a camera, atom_hud system still thinks you're at that z level, but your respected z should be changed to your current eye, because atom_hud should be supposed to show images on the z of where your eye is currently at.
  If I tell a case, abductors will not be capable of abductee marks through their camera. That's the issue in the new atom_hud port PR.

So, this is basic implementation for a new signal, like COMSIG_CLIENT_EYE_CHANGED to handle atom_hud's client images to show correct on z level
but also, it is a required system for

• Client image controller system + minor implementations #10789

Why do you need to have eye_weakref?

because DM immediately change your eye on mob/login(), and you lose which eye you had previously, even if your eye should be persistent.

So, where do you use eye_users?

If a thing is removed, and if it's a client's eye, we need to remove things from that client.

Example)

• Camera eye is made
• This camera eye is special, and you can see ghosts from this
• If a camera eye is no longer allowed to see ghost...
  • Step 1: SSclient_vision.revoke_vision_key_from_mob("ghost", camera_mob)
  • Step 2: Access camera_mob.eye_users
  • Step 3: Remove those ghost images from eye_users

How can you use SEND_SIGNAL(EYE_Z_CHANGE) from set_eye()?

If EYE_Z_CHANGE is sent, we need to access both client image systems: atom_hud and SSclient_vision
Both will handle which z objects should be removed from your client images, and which z objects should be newly added to you, based on your new client eye.

For example...

for(var/client/each_cli as anything in eye_users)
    SEND_SIGNAL(each_cli , COMSIG_CLIENT_EYE_Z_CHANGED, src, old_z, new_z)

because COMSIG_MOVABLE_Z_CHANGED is not capable of managing this

I think resolving weakref on mob/login() seems to be unnecessary.

It is necessary. just because it needs to remove your client from your old eye.

Why It's Good For The Game

Improving basic systems to progress further

Testing Photographs and Procedure

Screenshots&Videos

I've tested a lot locally. I figured it's working well.

https://youtu.be/k1axM8RbQXs

How new camera works

Changelog

🆑
code: minor port of set_eye() and reset_perspective() proc from TG, #PR 69115 (LemonInTheDark)
code: improved basic game system to track client's currently used eye
tweak: advanced camera is now visible by anyone even if it's currently used by someone. (This doesn't support the shuttle docking system, because it uses different one.)
fix: minor fix that advanced camera was still usable even if you're locker'ed
/:cl:

[Rukofamicom]

I believe it's safe to say that if this was going to break something it would have by now.
It's been testmerged for a week now.

[EvilDragonfiend]

This is trying to merge for 50 minutes. Definitely wrong... I will requeue it myself.