Allow hidden tasks in cue/flow

[jlongtine]

Allow hidden fields contain tasks would be very useful for us on the dagger team.

This PR adds a configuration field for cue/flow to enable hidden fields as tasks, and includes a small test.

[verdverm]

Would it be better to allow setting or passing an options slice for full configurability? What if another user wants to find tasks in definitions or optional values?

It seems best to allow the options to be passed, which would be a stable API, should the options change or expand.

[jlongtine]

@verdverm I'm not sure how that would play in this case.

These are the Options available:

• Final()
• Schema()
• Concrete(concrete bool)
• DisallowCycles(disallow bool)
• Raw()
• All()
• Docs(include bool)
• Definitions(include bool)
• Hidden(include bool)
• Optional(include bool)
• Attributes(include bool)

The only Options that make sense to me in this context are Hidden and Definitions. Perhaps All?

Having a Optional, Attributes, or Docs task doesn't compute with my mental model of tasks. Am I missing something here?

@myitcv @mpvl Any thoughts?

[verdverm]

@jlongtine My thought is to have an Options []cue.Option{} on the config object, rather than making something specific to Hidden. This is more flexible (developer configurable), concise, and future proofs any new options that may be made available. This is the same idea I think should be applied to the Walk function (i.e. https://cuetorials.com/go-api/basics/traversing/#custom-walk) and generally areas where Fields is called internally.

RE: recent slack message, a few thoughts

• A motivating example would be great to see
• A common reply to PRs without issues is that changes typically start with a proposal. (which would include a motivating example and a discussion into the design choices, rather than in the PR)
• Hidden fields are not visible across package imports, will this cause issue with your desired goals?

[myitcv]

Closing because this is superseded by https://review.gerrithub.io/c/cue-lang/cue/+/532797