Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.

Behaviour of existing clusters is unchanged.

All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.

Also removes all logic from ClusterConfigureWorker
and ClusterProjectConfigureWorker, which are also
no longer used.

- Set as uninstallable app
- Update docs
- Adjust specs

GitLab uses a kubernetes service account to perform deployments. For
serverless deployments to work as expected with externally created
clusters with their own knative installations (e.g. via Cloud Run), this
account requires additional permissions in the serving.knative.dev API
group.

Enable JIT Kubernetes resource creation for project level clusters

See merge request gitlab-org/gitlab-ce!29515

Since Kubernetes is creating the Secret and token asynchronously it is
necessary that we implement some delay or retrying logic to avoid a race
condition where we fetch a Secret before the token is even set. There
does not appear to be any way for us to force it to be set with any
synchronous API call so retrying seems to be the only option.

Previously this behaviour was only available to group
and instance-level clusters, as some project clusters
relied on Kubernetes credentials being passed through
to the runner instead of having their resources managed
by GitLab (which is not available when using JIT). These
clusters have been migrated to unmanaged, so resources
can be created on demand for the remaining managed clusters.

When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.

This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.

This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).

Immediate configuration is not ideal for group and instance
level clusters as projects that may never be deployed would
still have Kubernetes namespaces and service accounts created
for them.

As of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25586
we now create only the resources that are required for the
project being deployed, at the time of deployment.

Instance level clusters were already mostly supported, this change adds
admin area controllers for cluster CRUD