A rudimentary implementation of multiple access levels for the purpose of restrictive cargo ordering

[GansuLalan]

About the PR

Originally wanted to fix #7838 since the grand lottery haunts my funds but found it would require implementing a method to have multiple access levels on the same device as it's currently only one per. I therefore implemented a system to allow for such checking while still remaining compatible with current access methods and then implemented the restrictive cargo ordering as something of a demo/ test for the system.

Why / Balance

While the general idea of wanting multiple access levels is somewhat self explanatory, speaking from the perspective of a person who likes to QM, it is very easy for rouge techie to just order whatever since there is no restriction on self approval. I have personally watched addicted techies gamble the departments money away and although you can deal with them after the fact the damage is already done so prevention is somewhat ideal.

There is a level of concern about the removal of the chaotic factor the current system brings however as the occasional rouge techie can be amusing though that is a personal preference thing.

Technical details

AccessReaderComponent has a new variable for additional access lists, this can then be checked against via the normal AccessReaderSystem method by adding an index of the list to be checked against, the system will fall back to the general list if the given index doesn't appear to exist. This is all optional and to my knowledge the system can be used while pretending none of these changed happened. While I originally intended to change AccessLists, this proved awkward due to how abundant its use is in various prototypes and systems and also breaking the tests so such a change would require a larger refactor.

Changes to the cargo systems are to allow for restrictive ordering. The cargo order ui has been changed to add a checkbox that syncs across clients (hopefully) and can be changed by someone with QM access, this will then be tracked via a hashSet with a data class and checked against when an approval is attempted and will be denied unless approved by QM access or is unrestricted and then general approval can be given again.

There's also a fix for a telepad thing as the animation was crashing me during testing due to it attempting to be set twice

Other notes:
If anyone knows a better way to do Content.Client/Cargo/BUI/CargoOrderConsoleBoundUserInterface.cs line 186 better, please say as this my first time using xmal outside of small instances
I'm still new to ECS stuff so things might just be flat out bad, if so please let me know so I can improve them
I realise this might not be how such a concept is wished to be handled/ implemented, if so there's no worries, was an interesting problem to tackle anyways
UI could probably be improved, just uses the basic checkboxes for now
Having double checked the clips, might be a problem with the radio but it's late as of writing so will check/fix later

Media

Clips are a bit wavy, just trying to show off the system working

output2.mp4

Just showing emag works, most of the clip is just waiting for the money to come in

output1.mp4

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

None that I'm aware of, I tried to keep things as unintrusive as possible, there are new classes though

Changelog

🆑 Gansu

• add: Cargo orders can now be restricted and unrestricted by Quartermaster access. Restricted orders require approval by Quartermaster access.

[ArtisticRoomba]

Marking this as P1 because this directly contributes to #20064, mainly mechanically resisting powergaming.

[github-actions]

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

[GansuLalan]

It is apparently failing because of FlammableComponent? No idea why