Draft: fixes to not require cluster-level permissions for Flux/Workspaces

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

This MR probably isn't worth merging as it currently stands, but ideally should serve as a possible way of making GitLab Workspaces/GitLab Agent more usable. This addresses and solves some of the issues I identified in the Workspaces Beta feedback issue.

Overview of the changes:

• Reworks the Flux-installation checks to execute a list against the resource rather than looking up the CRD. This doesn't require cluster-level permissions as the API call will simply return an error if the CRD doesn't exist, or if the agent isn't authorised to use it.
• Reworks the Workspace reconciler to deploy workspaces to a single namespace. All informers and clients are scoped to the namespace that the agent is running in
• Reworks the Workspace deletion logic to delete resources listed in the inventory rather than just nuking the namespace. The reporting back to Rails is a bit janky but the actual deletion works fine

I have tested this on my homelab with my personal GitLab and it's working a charm. If you'd like to test it you can use this image: registry.gitlab.com/av1o/gitlab-agent/agentk:latest. It doesn't require any config changes, it just needs namespaced RBAC

If I had the time I would make the following additional changes:

• Ignore the config_to_apply sent by Rails and create a Workspace Kubernetes custom resource. Have an external Operator (e.g. created with the operator-sdk) watch this resource and create the Workspace kubernetes resources. This would allow me as the cluster operator to tweak the workspace deployment to fit my environment. This would also make deletion easier as the inventory would only ever contain a single resource and the Operator would handle resource cleanup

@bridley you might be interested in this 😉