Overhaul the waiting lobby user interface

[haykam821]

This pull request introduces a new design for the waiting lobby user interface, replacing the old item stack-based user interface that only appeared during team selection. Games can listen to the GameWaitingLobbyEvents.BUILD_UI_LAYOUT event to add custom elements to the user interface.

User interface elements are dynamically sized; if not enough space is available to provide the extended variants of each element, some elements will condense into their main variant. While this functionality is not implemented currently, the main element will allow players to access the extended variants in another way.

In the future, other user interface elements will be added; currently, only team selection elements are provided by default.

Breaking change: while there are no compile-level breaking changes, the fact that waiting lobbies enforce a hotbar user interface functionally is a breaking change. Games that manage the inventory themselves in the waiting lobby, such as to add a kit selector, should migrate to the GameWaitingLobbyEvents.BUILD_UI_LAYOUT event.

Some API design questions that should be considered include:

• How can games order the user interface elements? Would an integer or enum priority value resolve ordering issues?
• Is the current API design sufficient to allow for custom global user interface elements, such as elements to leave the game or open a party management user interface?
• How can user interface elements trigger a refresh of the user interface if their backing data has changed?
• Could the API package structure be improved?

[Patbox]

Genrally looks good.
For sorting layouts, you could add identifier based prorities, like fabric events.
Also it might be good thing to check if players can interact with blocks and entities when with this gui, so you don't prevent some in world interactions games might want to use.

[haykam821]

I worry that computing an ordering graph might be a bit complex for the initial implementation, though the API surface seems reasonably simple: each element would provide a unique identifier, and layouts would allow adding adding elements before or after such an identifier. I suppose unit testing would help validate the mechanics.

[Patbox]

Yeah fair. It can be added later down the line in api compatible way so it's nothing blocking. The world/entity interaction is more important thing that needs to keep working