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 and reusing sub-subspaces (uses icon button for subspaces, since having two text buttons and an icon-button takes up half the screen on mobile devices)
• Adds a check to prevent creating infinite loops
• 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).
• A new/reworked Lobby UI that is designed around nested spaces, as the current UI works but could definitely be improved)
• Categories only closing when all parents are closed can be somewhat confusing, so being able to manage this per rendered instance would be nice.
• Powerlevel propagation (i.e. default powerlevel for different members is copied from the parent space)

Additional Notes

There is some possible de-duplication that probably should be done, as the getInClosedCategories and getAllAncestorsCollapsed functions are very similar in Lobby.tsx and Space.tsx, do say if I should move them to a separate file, and if so where that file should be located. Related to this, merging makeLobbyCategoryId, makeNavCategoryId (and their new respective getXXXXCategoryIdParts) into a single makeCategoryId would simplify things quite a bit, as this is now also used in useSpaceHierarchy.tsx.

Example image:

Fixes #1855 , Fixes #2056

Type of change

• Bug fix (non-breaking change which fixes an issue)
• 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:

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

[github-actions]

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.

[GimleLarpes]

So with Discord having a moment, and the resulting jump in Cinny's popularity I decided to revive this PR.
It's functionally complete and ready to merge, with some possible refactoring needed.

Preview link, since it got a bit buried:
https://2385--pr-cinny.netlify.app/