Support nested RoadContainers

[TheDuckCow]

Having thought more about the example of providing off the shelf highway interchanges, per here, I realize that it really will in fact be important that saved subscenes can contain more than just one top-level RoadContainer. They should be able to contain nested RoadContainers.

This will allow for features like:

• Grouping different sections of a road (bridge, flat, etc) into one top-level road, which is useful for organization in complex scenes
• Allow users to create and save more complex segments of roads. This is specially true for complex intersections like highway interchanges, which by definition are really composites of multiple intersections
• As a side consequence, we'd also make it so that saved RoadContainers with no material defined look to their parent RoadContainers to get a material. This means that the plugin could ship with a bunch of pre-defined intersections layouts (e.g. highway clover leafs) but then on import, already inherits the material loaded from the parent RoadContainer if any.

Open questions:

• How to deal with connections with multiple nested RoadContainers?
  • The connection logic is already feeling a little complex, since we have to treat subscenes as solid unmodifiable blocks.
  • We should probably enforce only allowing connections to top-level RoadContainers
• Do we allow for a mixture of "layers", e.g. if one RoadContainer is nested in another, do all RoadPoints need to be nested within another RoadContainer?
  • One nice thing about the current structure is that we force all RoadPoints to be at the same hierarchical depth, which is useful.
• How to propagate settings?
  • I think it's fair that the lowest-down RoadContainer has ultimate authority over its own RoadPoints
  • We would probably introduce more "pass through" values (e.g. how -1 for density means "inherent from the parent RoadManager" already today, could just go "up the chain")
• To consider, do we really need to force RoadContainers being the root of a saved subscene? This could be a good time to change that
  • Someone who wants to save e.g. a highway reststop as a whole prefab scene, might want to define their own root node controller for this scene, which would include both roads as well as buildings, maybe trees and grass, and interactions. With the current structure, we force the hand of developers by prioritizing the RoadContainer as being the root, which isn't ideal in all cases.

[TheDuckCow]

It's worth calling out that, in some sense, we do already support nested RoadContainers:

But what is lacking:

• The edges calculated are still just showing the open connections of the direct child RoadPoints, it should be showing all edge points and accounting for sub-container connected segments which should discount an otherwise edge roadpoint
• Ideally we can infer both the material and density from the parent-most road container. TBH would be nice if all settings could be inferred from the parent if not overwritten, but then we'd need to turn everything into an enum instead of a bool, which is rather annoying (e.g. whether to generate AI lanes, or to display them in the editor).
• If we just have a top-level container and children which are other containers, it actually works ok in terms of edges. But if we mix the level of roadpoint children and container children (which tbh, might be nice to be able to do, e.g if you want to throw in a bridge prefab in the middle of an otherwise singly contained road), it's a bit more ambiguous how to traverse. Should we add a padding "roadpoint" on the other side of the added bridge, in case it's at the end, so that container edges are always directly referencing direct child roadpoints? Could lead to lots of excessive nodes.

[TheDuckCow]

Worth prioritizing this one after https://github.com/TheDuckCow/godot-road-generator/issues/118 is implemented. (could also be a good one for Bdog at that point, so won't start right away)