Concurrent Component Compiler

[jeffmccune]

Pass core.Component via standard input from holos render platform to a pool of holos compile sub processes.

Purpose:

1. Forces us to define a protocol and message for passing all context necessary to compile a BuildPlan. Passing data through cue tags has introduced friction and debt complicating backwards compatible changes to the behavior of the tool.
2. Unlocks cue concurrency. Cue is not safe for concurrent use within the context of one go process. Testing indicates at least a 500% speedup on a 14 core cpu. Often 1000% after caches are warm.

Requirements:

1. Must support v1alpha5
2. Must support v1alpha6
3. Must not block future plans such as TaskSet as an alternative to BuildPlan

Plan:

1. Wire the compiler to holos show buildplans, use it to produce each buildplan concurrently.
2. Use holos compare buildplans to ensure the output is equivalent to v0.104.1
3. Wire the compiler to holos render platform.
4. Verify all manifests in deploy directory are equivalent to v0.104.1

[jeffmccune]

#391 is another case where it could have been a quick thing to implement, but ended up taking a lot more time since we'd need to wire experiments through flags from holos render platform to holos render component.

The development slow down comes from two main places:

1. wiring up flags
2. holow show platform behaves differently

Ideally when we solve this we define a protocol to pass a core.Component, then wrap that core.Component in a builder.Component which should ideally take on more of the responsiblity of constructing the cue context in a consistent way.