Expose the GOARCH runtime constant to CLI users

[jpluscplusm]

Is your feature request related to a problem? Please describe.

I'd like to access information about the runtime that's executing the cue CLI, so I can fetch appropriate binaries for an outside-of-CUE-land purpose. I can already access the OS information via the os system tag, and it seems like a bit of an arbitrary choice not to be able to do the same for the only other similarly-situated runtime variable that Go makes available: runtime.GOARCH.

Describe the solution you'd like

I'd like arch to be available as a system tag, when the --inject-vars flag is used.

I have implemented this as PR #1689.

Describe alternatives you've considered

I currently hackily script around the cue invocation and interrogate various uname outputs. I have an incomplete map of uname -m to possible GOARCH variants that I populate manually, and feed into the cue invocation as tags. The CLI runtime has this information available at its fingertips, and it doesn't seem like a stretch to ask it to expose the info.

Additional context

Go's runtime package makes 3 top-level constants available: the name of the tool that built the running binary, the OS, and the architecture. Of those, only the last 2 are relevant to the in-CUE consumer, and it seems arbitrary to make only 1 of them available as a system variable.

I don't believe there's a slippery-slope argument to counter, here. The associated PR (#1689) isn't serving as precedent to open the flood gates to a wider set of variables: it's just going some small way to realign the capabilities of cue CLI users with folks who are consuming CUE in Go.

[myitcv]

I vaguely remember this coming up at the time we introduced tag vars. Sounds good to me. But I defer to @mpvl for a final decision.

[mpvl]

Yes, adding the arch is in line with the other supported values.