Implement dynamic content for the sidebar (config.json) driven by relations rather than the default static version

[ca-scribner]

The sidebar content (links to Notebooks, Experiments, ...) is defined statically in src/config.json, which gets deployed as a configmap. These links will exist regardless of whether the associated component exists, and must be defined based on our best guess of what features kubeflow will be deployed with. If users add/remove features, they either have to fork the charm, modify the configmap themselves after deploy, or use the dashboard-configmap charm config option to point at a different configmap.

Using relations, we could allow dashboards to subscribe into the central dashboard and the dashboard can reflect what is deployed right now. Something like juju relate kubeflow-dashboard:menuLinks kfp-ui:menuLinks, which would trigger an update to the configmap. This would let the dashboard reflect this particular user's deployment easily and be a nice advantage of a charmed kubeflow.

Downsides/complications I can think of to this:

• ordering of links might get a little odd as it could change
• adds several relations (katib, pipelines, notebooks, volumes, etc., all need to relate to this charm)
• technically the links would only work if the subscribing dashboard has also subscribed to istio ingress (otherwise the link will be dead), but I guess that's just as bad as if a charm subscribes with a broken link?

[DnPlas]

Fixed by #38