Export context extensions for space metadata

[RedbackThomson]

Description of your changes

Create a new SpaceExtension type, defined as runtime.Object, to be used in Context.Extensions output by the Accept command. Stores a different configuration depending on whether the underlying space for the context is backed by Upbound cloud or is disconnected.

As of this PR, we don't use the extension data in any part of up ctx but in the future it will be used to:

• More easily derive the state (cloud vs. disconnected) without requiring lookups
• Point the upbound context at the space hub cluster, when using a disconnected space, instead of creating a new cluster using the ingress
• More easily derive the cloud organization without requiring gross hacks

Example of a cloud kubeconfig with an extension:

apiVersion: v1
clusters:
- cluster:
    insecure-skip-tls-verify: true
    server: https://upbound-gcp-us-west-1.space.mxe.upbound.services
  name: upbound
contexts:
- context:
    cluster: upbound
    extensions:
    - extension:
        apiVersion: spaces.upbound.io/v1alpha1
        kind: SpaceExtension
        spec:
          cloud:
            organization: upbound
      name: spaces.upbound.io/space
    namespace: nicks-group
    user: upbound
  name: upbound
current-context: upbound
kind: Config
preferences: {}
users:
- name: upbound
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      args:
      - organization
      - token
      command: up
      env:
      - name: ORGANIZATION
        value: upbound
      - name: UP_PROFILE
        value: staging
      interactiveMode: IfAvailable
      provideClusterInfo: false

I have:

• [x] Read and followed Upbound's contribution process.
• [x] Run make reviewable to ensure this PR is ready for review.
• [ ] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested

Added some basic unit tests to assert the extensions are being added to the kubeconfig when accepting a group or ctp

[sttts]

Point the upbound context at the space hub cluster, when using a disconnected space, instead of creating a new cluster using the ingress

Does this mean up will switch to the ingress as soon as I attach the Space, and it will not for disconnected? Or does this rather depend "where we are coming from", i.e. when on a hub context, we remember that fact via extension and come back to the hub later?

[sttts]

Hmm, not working for me:

$ gcloud get credentials ....
$ up ctx
up: error: ctx.Cmd.Run(): failed to get API group resources: unable to retrieve the complete list of server APIs: v1: the server has asked for the client to provide credentials

[RedbackThomson]

Does this mean up will switch to the ingress as soon as I attach the Space, and it will not for disconnected? Or does this rather depend "where we are coming from", i.e. when on a hub context, we remember that fact via extension and come back to the hub later?

None of this is implemented as part of this PR, so I don't have a definitive answer for you yet. My idea was that we would always store a pointer to the hub cluster and whenever we point back to the group level, we would point at that cluster instead of creating a new one.