frontend Map: Allow plugins to customize the map

[sniok]

Basic Map extension

This PR introduces 3 new functions that allow for the simplest case of extending the Map.

You can read the full docs page over here https://github.com/headlamp-k8s/headlamp/blob/d02531292dd770360d127a792d345e82428ad994/docs/development/plugins/functionality/extending-the-map.md

You can add your own nodes and edges, customize the icon for the nodes and show a details page for the node.

1. registerMapSource
   registers a "Source" which provides Nodes and Edges to the map

2. registerKindIcon
   adds an icon for a specific resource "kind", which is displayed on the node and the map search (not the global one)

3. registerKindDetailsPage
   registers details panel for a specific resource "kind"

Reasoning and intentions

The registerKindIcon and registerKindDetailsPage don't mention Map and have a generic name (and not registerMapNodeIcon for example) for a reason.
I think in the near future this can be used in other places and not just Map.
For example KindIcon can be used in the global search, and Details component can be used in the normal Details page for custom resources.
For now the customizations are very granular to keep it simple but I think in the future we should have an ability to register a custom resource that will integrate it everywhere all at once, something like this:

registerCustomResource(params) {
  registerKindIcon(...);
  registerKindDetailsPage(...);
  registerMapSource(...);
  registerGlobalSearch(...);
  registerSidebarItem(...);
  registerRoute(...);
}

which I think would be extremely useful since a lot of plugins are listing/displaying custom resources.

[joaquimrocha]

This looks very reasonable. I have 2 questions, however:

1. Does it makes sense somehow to unify the details page for the map and for other places?Right now we have the notion of a details route, associated with a KubeObject, but a component is registered for this just as a normal route by using registerRoute.
2. I think the "framework" you are proposing matches a lot the case where we want to display kubernetes resources, but I wonder if it makes sense to abstract it to something that is not Kubernetes specific. Say e.g. we want to display users? Or we want to display clusters?

[sniok]

1. Does it makes sense somehow to unify the details page for the map and for other places?Right now we have the notion of a details route, associated with a KubeObject, but a component is registered for this just as a normal route by using registerRoute.

Absolutely, I think would be perfect for adding details page, especially for custom resources. Even now we could already replace all routes to render KubeObjectDetails component.

2. I think the "framework" you are proposing matches a lot the case where we want to display kubernetes resources, but I wonder if it makes sense to abstract it to something that is not Kubernetes specific. Say e.g. we want to display users? Or we want to display clusters?

Yes it can support other objects as well, when we register a source it currently only returns nodes with the type "kubeObject" but it can return any type. The only missing piece for now is registering custom node type.

So it is going to look something like this:

// register customUser type
registerNodeType('customUser', { renderNode: (nodeData) => <div>{nodeData.name}</div> } ))

registerMapSource({
   useData() {
      // specify type and pass any data
      return {  nodes: [{ id: 'some-user', type: 'customUser', data: { name: 'user-name' } }] }
   }
})

[sniok]

Removed the registerKindDetailsPage method from this PR as it needs some more investigation and thought