Differences between standalone and kubeflow modes of our web apps

There are many cases where users would like to install specific components of Kubeflow and not the entire solution. To accommodate this need we will have to engineer our web apps to be deploy-able as standalone components as well.

This issue aims to provide a cohesive story around how we want our web apps to behave when they are installed as part of Kubeflow or as standalone components. It's an effort to document the technical details as well as the design decisions to achieve this.

Once we have a solid understanding and ironed out most of the important details then we can convert the knowledge and discussions from this issue into a design doc.

## Kubeflow mode
When we say that an app is deployed alongside Kubeflow this means the following things:
1. There is **always** a logged in user.
* This is enforced in a central place which can be IAP, Dex etc. The user first logins to this central entity and then navigates to Kubeflow. This entity places the username in a configurable header in each request that passes from it
* The backend of each app will be checking that header to deduce the identity of the user and will creating [SubjectAccessReviews](https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1/) to ensure the user is authorized to perform an action https://github.com/kubeflow/community/pull/334
2. There is a CentralDashboard which
* decides what Namespaces to show to the user and feeds to the app the selected Namespace
* has a left hand sidebar, which can have subsections https://github.com/kubeflow/kubeflow/pull/5474. This side bar can be used for navigating the user between different pages of the underlying deployed app

## Standalone mode
This means that only this app is exposed and no other Kubeflow component. This introduces the following consequences that the web apps need to handle:
1. There is no CentralDashboard
* the app must handle it's navigation to different pages on each own
* it must handle Namespace selection on its own
2. There is no guarantee that there will be an authentication system, a logged in user. This leads into two scenarios:
* if there is such a system then it must be setting the user identity in a specific header. This header is configurable for our web apps. If a custom one is used the admin can let the app know which header to look for. In this case the app relies on `SubjectAccessReviews` to ensure the user is authorized.
* if there is no such a system then we expect that every user is admin and can do anything they want in any namespace. In this case the backend must be configurable to not perform any authnz checks

Start by reviewing the Kubeflow-mode and standalone-mode requirements in this issue, including the CentralDashboard, IAP/Dex, configurable identity headers, and SubjectAccessReviews references. Document the unresolved design decisions and define a cohesive behavior for navigation, namespace selection, authentication, and authorization; done means the decisions can be converted into a design document.

Written by the indexing model from the issue text.