Render Single Component

[srueg]

Render a single component by faking the required parts of the inventory. Additional classes can be specified with the --values/-f flag (multiple possible).
For the compilation to succeed, a user is responsible to provide all required parameters (which are not covered in the defaults.yml).

This changes the CLI structure: There's two new command groups: catalog and component. The previous compile and clean commands are moved to the catalog group and the new-component was moved together with the compile-component command into the component group:

commodore component new
commodore component compile
commodore catalog compile

This first implementation doesn't support secret refs. This means all used secret refs in the defaults.yml must be overridden with concrete values in the provided classes.
Vault secret refs are supported and get revealed to the path they reference (e.g. ?{vaultkv:${customer:name}/${cluster:name}/backup-cluster-objects/password} becomes t-silent-test-1234/c-green-test-1234/backup-cluster-objects/password)

Closes #74

[srueg]

Not done yet / Caveats:

• The argocd.libjsonnet library is being faked with an empty object, therefore the Argo CD application manifest won't be rendered

• Other component libs can't be used

  • Provide additional search path to fake libs

• No jsonnet lib dependencies are created, therefore the kube.libjsonnet is missing (which breaks many components)

  • Try to reuse current dependency management

• Parameters defined in target.yml can't be overridden

  • Instead of faking the cluster facts to the target directly, create a class to include, in order to allow overriding of facts etc.

• Output is rendered to /tmp

  • Specify output with flag --output/-o

[srueg]

I fixed the remaining open points and was even able to find a solution to support vault references: By creating a fake VaultBackend, references are "revealed" to the path in Vault they specify.

[simu]

LGTM overall. Feel free to do the _relsymlink refactoring or not.

[corvus-ch]

This PR has fallen into classic scope creep. From what I can see, I would have made at least three PRs out of this.

1. Remove the build component test container image build
2. Restructure
3. Add the functionality

Why? Because this results in smaller commits with a more narrow scope and thus are easier to review. It also allows to separate discussions from each other. I might question one thing but agree with others. If in a separate PR, I can approve the one and discuss on the other.

Yes I am aware of the fact that some changes rely on each other. But combining them is what in german we call a Mogelpackung which might work in politics but should not be done in software engineering.

[srueg]

I moved as many changes into own PRs as possible. This last one still includes the change of command structure and the actual component compile functionality since they're too closely intertwined.
PR #130 needs to be merged first since it switches to using the Kapitan library instead of running the binary.