Fully convert to a builder/IR for analyzing input

[sdboyer]

#48 began a journey towards a builder/IR-style approach to analyzing CUE inputs as part of outputting them. This issue is for outlining the path to achieving that.

From where we are now, it seems to me that intermediate goals/milestones would be:

• Replace the generator with the standalone buildContext introduced in Sorta-introduce new system for building output #48
• Create individual builder/IR-types representing the different output targets, but having some shared interface
• Refactor utility functions (e.g. tsprintField()) to avoid doing much analysis, moving as much of this as possible instead into the typed builders
• Create a system of general rules for defining what describing and checking the permissibility of inputs

This last point would be especially valuable, as it would be a basis for explaining to the user what they are and are not allowed to input.

It's also possible that the introduction of a partial evaluator within the language facilities - basically, a new Eval() which can be told to preserve unchanged any nodes marked with a particular attribute - could obviate the need for a lot of the complexity in such an IR. If my thinking on this is correct, then at minimum, such a call could ensure simplification of the input cue.Value is a strictly smaller, better-defined superset of the graph of IR nodes that need to exist.