Client distinguish between eye and mob for drawing, context menu, and verbs

[Ruzihm]

Adds a network message sent from the server to client to notify of mob/eye updates (currently, the client uses the attached entity which is ambiguous). I wasn't sure of a better way to accomplish this but am looking for feedback.

The client then uses this info to distinguish between eye/mob for context menu, drawing, and verbs.

Closes #1581
Closes #2081

[Ruzihm]

I'm not sure why but when I tried to register this in DreamClientSystem I would get the following error & disconnect:

[WARN] net: 127.0.0.1:1212: Got net message with invalid ID 72.
[DEBG] net: "127.0.0.1:1212": Status changed to Disconnecting, reason: "Got NetMessage with invalid ID"

I don't know of a better way to handle this so I'm just leaving this here for now for proof of concept until a better method is suggested.

[Ruzihm]

actually - one sec. z levels and mouse events are messed up when eye is a turf.

edit: should be good now

[Ruzihm]

Setting eye to null will stop rendering - but since that's done by setting the eye position to be in nullspace, the viewport stops clearing the render target and you just get a frozen screen:

https://github.com/space-wizards/RobustToolbox/blob/aa5cca4c7f210f3ed7b7841735b5aadb533c9d88/Robust.Client/Graphics/Clyde/Clyde.HLR.cs#L494-L497

Does this warrant a pull request to RT to add a viewport option to allow target clearing if there is no eye/the eye is in null space?

[wixoaGit]

Does this warrant a pull request to RT to add a viewport option to allow target clearing if there is no eye/the eye is in null space?

I think that would be better as the default instead of an option, but I suppose that's up to the RT maintainers.

[Ruzihm]

So turns out that RT patch wouldn't help since a null eye should still render screen space elements in non-negative planes. PR should now account for that.