(#150) Refactor PlatformService.GetConfig for use with CUE

[jeffmccune]

See #150

Problem: The GetConfig response value isn't directly usable with CUE without some gymnastics.

Solution: Refactor the protobuf definition and response output to make the user defined and supplied config values provided by the API directly usable in the CUE code that defines the platform.

Result:

The top level platform config is directly usable in the internal/platforms/bare directory:

grpcurl -H "x-oidc-id-token: $(holos token)" -d '{"platform_id":"'${platformID}'"}' $host \
  holos.v1alpha1.PlatformService.GetConfig \
  > platform.holos.json

Vet the user supplied data:

cue vet ./ -d '#PlatformConfig' platform.holos.json

Build the holos component. The ConfigMap consumes the user supplied data:

cue export --out yaml -t cluster=k2 ./components/configmap platform.holos.json \
  | yq .spec.components

Note the data provided by the input form is embedded into the ConfigMap managed by Holos:

KubernetesObjectsList:
  - metadata:
      name: platform-configmap
    apiObjectMap:
      ConfigMap:
        platform: |
          metadata:
            name: platform
            namespace: default
            labels:
              app.holos.run/managed: "true"
          data:
            platform: |
              kind: Platform
              spec:
                config:
                  user:
                    sections:
                      org:
                        fields:
                          contactEmail: jeff@openinfrastructure.co
                          displayName: Open Infrastructure Services LLC
                          domain: ois.run
                          name: ois
              apiVersion: app.holos.run/v1alpha1
              metadata:
                name: bare
                labels: {}
                annotations: {}
              holos:
                flags:
                  cluster: k2
          kind: ConfigMap
          apiVersion: v1
    Skip: false