FYI: If we had running unittests, they would fail because of backwards incompatible changes here. They aren't major changes, but still the behavior is slightly different.

I changed the backend menu to use the MenuItem class and re-ordered a lot of code as well. This makes about a 1000 lines of code obsolete...

These changes had 3 goals:

1. Make the Joomla\CMS\Menu\Node class obsolete, since it is a copy of MenuItem of this PR.
2. Reduce the code necessary for the backend menu.
3. Make the code easier to understand.

I succeeded with 1. and as you can see reduced the code quite a bit, but it still isn't easy to understand. sigh

The current implementation works in a way that is very strange to me... I don't even really know how to explain how it works. I felt uncomfortable working with first flat lists, then converting those into a pseudo-tree, then converting that again into a "real" tree, but being unable to access that without going through the Tree class first... The new implementation now works with nodes of type MenuItem right from the start and then modifies and iterates the whole tree afterwards. The code still is pretty complex, but I hope that I reduced the complexity by a degree. Maybe from a 10 to a 9?

I also moved code from the Joomla\CMS\Menu\MenuHelper to the MenusHelper of com_menus, because we are already using code from that class in that whole system and I couldn't see a reason for having some code in the component and other code in the framework. Since this is highly application specific code, I decided to move this entirely to the components MenusHelper and to drop the framework class. This reduces the rendering of the backend menu from 10 files down to 3.

One detail that I feel a bit uncomfortable with is removing the Joomla\CMS\Menu\Node* classes. The backend menu has special classes for each node type which contain some special handling and which I would consider a rather better implementation than what is in this PR. But I decided against those node-type-classes since it brings the backend menu closer to a copy of the frontend menu. At the same time, there is so much special logic in the code to render the menu, that a little bit more to acommodate for this wont change the overall impression of this noticeably.

The part of creating your own backend menu has to be tested again, but shouldn't be far off from what we expect.

@wilsonge I hope that raises the chance to merge this. If you want to know a different reason to make MenuItem implement the NodeInterface: With this change, you could dynamically extend the menu system during runtime. You could generate menu items from categories and insert them wherever you want by doing addChild(), etc. and it would automatically propagate through routing and menu displays without storing this in the DB. It would make the menu more flexible. ;-)

Deprecation notices are added in #23842

I have tested this item ✅ successfully on cf51ece

I have tested this successfully - from the user's point of view - without code inspection.
I used 5 levels of categories. Some with articles and some without.
In Backend and Frontend, the tested structure looks equal after patch and before patch and links work as expected.

The amount of categories was not sufficient to say anything about performance.

Thanks for being patient with this!