Organize the code to make resource types more easily pluggable

[bgrant0607]

Most of the UI plugin is general-purpose, except for resource-type-specific code.

That code is currently spread across multiple files and directories:
https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/types
https://github.com/GoogleContainerTools/kpt-backstage-plugins/blob/main/plugins/cad/src/components/ResourceEditorDialog/components/FirstClassEditorSelector.tsx
https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/components/ResourceEditorDialog/components/FirstClassEditors
https://github.com/GoogleContainerTools/kpt-backstage-plugins/blob/main/plugins/cad/src/components/ResourceViewerDialog/components/FirstClassViewerSelector.tsx
https://github.com/GoogleContainerTools/kpt-backstage-plugins/tree/main/plugins/cad/src/components/ResourceViewerDialog/components/FirstClassViewers/StructuredMetadata/resources

and possibly other places.

It would be useful for resource-type-specific implementations to be self-contained, so that they could be easily added, eventually without a fork of the plugin. That would enable other projects to add types relevant to them: Kubernetes types, Config Connector types, ArgoCD types, Gatekeeper types, Istio types, etc.

At least until we're able to autogenerate UI forms from resource definitions. :-)

[bgrant0607]

We'll also want a mechanism for grouping resource types in navigation.

Most of supported resource types currently relate to Namespaces and Namespace-scoped policies.

When we add application resource types (kptdev/kpt#3351), that will add quite a few more.

Support for Config Connector would add even more.

Some types, such as Kptfile and ApplyReplacements, are independent of specific use cases.