Create a separate resource type for each UCP plane

[rynowak]

Forking off from a discussion in https://github.com/project-radius/radius/pull/3493/files#diff-95dbdd451b47bf002fb28d7dfe9835e6eba318925b57426b90f057451e3f043b

Currently we use the same controller implementation and resource type for all UCP planes. The resource type has a discriminator field for the kind of plane. This design is not straightforward and pushes a lot of complexity into the public API of Radius. Discriminators should be avoided except when they are the last resort.

A comparatively simpler design is to use a different resource type and controller for each plane. This way we don't see features leak between the different planes, and can simplify the API. The URL structure already reflects the design we want, but the resource body does not. Our controller framework has evolved significantly since we started on UCP and we can take advantage of that by pivoting the design.

AB#4504

[vinayada1]

More from discussion with Ryan: We should aim for each plane controller to be a separate microservice eventually. For example, AWS plane handling could be in a separate microservice. We should start refactoring the code with this goal in mind.

Right now all planes and routes all have to be in router.go. We could use nested routers where a router calls a function and the function could do something and also add a new router. Where the route is handled can be answered by asking the question - is this a url for managing planes or is this an operation on a specific plane.

[sylvainsf]

@rynowak is this still valid?