cmd/cue/cmd: add go tag for or expressions

[LucasLundJensen]

This adds a new Go tag which allows the use of OR expressions when generating Cue based on Go.

I'm aware that this change might not be the desired way of resolving the lack of having OR expressions available based on tags in cue tags in Go structs.
If that is the case, take this PR as more of a discussion on how to properly implement this.

I've got the need for this feature, as it'll allow me and my team to generate CUE schemas purely based on our Go structs with the desired defaults that we intend to have on those fields.
A more concrete example is the following:

type Module struct {
	Org string `json:"org,omitempty" yaml:"org,omitempty" cue_or:"*\"org_name\""`
}

#Module: {
	org?: string | *"org_name" @go(Org)
}

Where as the only tag available today cue only supports AND expressions.

[mvdan]

Our thinking in this space is to provide the opposite of cue get go, so that you can define your schemas in CUE as the source of truth, and generate Go types which approximate the shapes well enough so that you can decode CUE values into Go.

This is ultimately the most flexible approach, as you can define as many constraints on the CUE side as you want, without having to somehow fit everything into Go struct field tags. We also find that to be more consistent, because we tend to want to write CUE validation and other logic alongside the schema definition, so it's a bit odd if the schema's source of truth is in a Go file separate from the rest of the CUE.

I'm currently working on this as we need it ourselves - the first version will be experimental and fairly simple, but I believe we can extend it to support most use cases.

[mvdan]

And I forgot to say - thank you for contributing!

[LucasLundJensen]

Our thinking in this space is to provide the opposite of cue get go, so that you can define your schemas in CUE as the source of truth, and generate Go types which approximate the shapes well enough so that you can decode CUE values into Go.

This is ultimately the most flexible approach, as you can define as many constraints on the CUE side as you want, without having to somehow fit everything into Go struct field tags. We also find that to be more consistent, because we tend to want to write CUE validation and other logic alongside the schema definition, so it's a bit odd if the schema's source of truth is in a Go file separate from the rest of the CUE.

I'm currently working on this as we need it ourselves - the first version will be experimental and fairly simple, but I believe we can extend it to support most use cases.

This is exactly the route we wanted to go in the first place, but realized that it wasn't entirely possible yet.
Hence why this is our approach currently, but we'd be excited to switch over to having CUE be our source of truth later on.