feat: Cue spec validation

[adamperlin]

What this PR does / why we need it:
Currently, Dalec specs are validated using a mixture of strict YAML unmarshalling and manual validation of the unmarshaled spec in Go code. This PR allows us to concretely specify a schema for Dalec specs using Cue, and then utilize Cue for almost all spec validation. This has a number of benefits:

1. It removes the need for some of the currently existing validation code within Dalec, within which it is hard to account for every error case.
2. It allows us to add new spec validations easily and declaratively, without changing Go validation code

• As a proof of concept for this, the Cue spec included in this PR places additional restrictions on source names

3. It gives us a model to use for generating templated YAML which is correct-by-construction. We can use the Cue spec included here to create templates which can be used for generating starter spec stubs for new Dalec users, as well as creating templates over subcomponents of the Dalec spec (i.e., reducing boilerplate for particular commonly used sources, and any number of other tasks).

I am opening this as a draft mostly for discussion. All the current test cases in the repo are passing. I do have some concerns with user friendliness, as cue's error messages aren't always the nicest and take a bit of getting used to. They do however nearly always point to the specific field (or lack of field) which is causing the issue.

Which issue(s) this PR fixes (optional, using fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when the PR gets merged):
Fixes #132

Special notes for your reviewer:

[adamperlin]

It is a little annoying to have to specify dates this way. I'm going to look into whether this can be cleaner

[adamperlin]

We do need to be explicit now about string vs. int values for env variables in the yaml itself

[pmengelbert]

That's a major gotcha in YAML. I think it's worth investigating if there's a way you can get CUE to interpret values in certain structures as strings. I'm not sure that it's possible but it may be.

[pmengelbert]

It is definitely worthwhile to capture all of the defaults in this PR. We actually have extensive defaults, mostly undocumented.

[adamperlin]

Some further things to investigate:

• Could we use returned error values from cue to provide more user-friendly and Dalec specific validation messages? For instance, something like validation error in field x.y.z, expected values are: ... I.e., can we avoid exposing users to extra cue concepts that may not be relevant, i.e. cue value unification
• Further regexes to constrain URLs, semvers, etc.
• Try to encapsulate all Dalec defaults in Cue spec

[cpuguy83]

If we were to adopt this, I think we'd need to generate go types from the cue.

[MorrisLaw]

nit:

Suggested change

	var retErrs []error = make([]error, 0, len(errs))
	retErrs := make([]error, 0, len(errs))

[MorrisLaw]

nit:

Suggested change

	cueCtx := cuecontext.New()
	v := cueCtx.CompileString(cueSpec)
	ctx := cuecontext.New()
	v := ctx.CompileString(cueSpec)