Add: Improve subspace display

[GimleLarpes]

Description

Improving the handling of sub-subspaces has been requested in #1855 and #2056. This PR aims to properly display sub-subspaces (and deeper) in a more intuitive tree structure, which better conveys relationships between spaces, as well as improves their organization and navigation.

Currently sub-subspaces and lower are simply flattened to the end of the subspaces, with no regard for their parent subspace. This can be confusing and difficult to navigate, especially in large organizations or bridges.

This PR:

• De-flattens sub-subspaces and displays them under their parents with an indent
• Sub-subspaces are treated as items under their parent space (are collapsed when their parents are collapsed)
• Enables functionality for creating sub-subspaces (uses icon button for subspaces, since having two text buttons and an icon-button takes up half the screen on mobile devices)
• Fixes a bug where reordering a room could sometimes remove it from roomToParents

This PR is limited in scope, possible future improvements could be: Adding a better way to easily reorganize subspaces in Lobby (drag subspaces into and out of spaces).

Example image:

Fixes #1855 , Fixes #2056

Type of change

• [x] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [o] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [o] This change requires a documentation update

Checklist:

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings

[github-actions[bot]]

Preview: https://2385--pr-cinny.netlify.app ⚠️ Exercise caution. Use test accounts. ⚠️

[GigiaJ]

Not sure if we want it to be indented even if there are no rooms in the above sub-spaces. Actually just opening a dialogue for this since I actually have no preference. I see the value of either option. Outside that, beautiful work.

[GimleLarpes]

That is indeed not intentional. The best behaviour would probably be to create the room header if the space contains either a normal room or a space. My bad!

Edit: I just realized doing this might be trickier than I at first thought; Unless a ~~pretty expensive~~ recursive check is done in getSpaceJoinedHierarchy, you could have a space containing a subspace (so it would be displayed), with that subspace being empty (thus not displayed). This would then show an empty category.

My question now is: How important is it to not show empty spaces even if they exist?

[GimleLarpes]

I think this should be ready for review now.