Solve the explosion of cluster applications problem

Right now it appears that we handle helm applications in a somewhat generic way but in reality our backend code and frontend code involves a lot of copy and paste for each application type and then we end up writing custom JS and Ruby (eg. ip address for ingress, runner registration token, jupyterhub URL) for each application type.

This approach is not going to scale and furthermore the more apps we add this way the harder it will be for us to make generic improvements to this feature in future (eg. generic solution that works for groups and projects and instance wide clusters or just any new features related to helm applications in general).

We should discuss approaches to this problem so that adding a new application does not involve copying and pasting so much ruby and JS code but is more of a configuration change.

Some suggestions about what the framework should look like is:

• Perhaps a JSON endpoint in our backend that gives list to frontend to dynamically generate the applications list (ie. frontend should not know any specifics and therefore specifics live in only one place)
• We know there are slight differences in the UI so we'll need a generic way to represent these differences (eg. a JSON description of a form to render with extra metadata about the installed app)
• We may wish to support editable form fields for customisations of installed apps in future (eg. edit the domain names for ingress or knative triggers)
• We may wish to have a low level framework that is maintained by ~Configure (or perhaps ~Monitoring) team but then the higher level details of each cluster can be configured more easily by other teams that need to add their own apps like ~Monitoring and ~"CI/CD" and possibly others in future