Move BuildStep out of corev1.Container

[qu1queee]

Idea:

From the last grooming session and mainly based on the discussions in #516 ( as part of our API review ), we agreed on stop using corev1.Container in the definition of a Build step.

Main reasons for the above are explained in here, but in a nutshell is due to the amount of extra fields we do not use from corev1.Container.

The end-goal on this card is to leverage the usage of the Script feature of Tekton, as seen in their own Step definition. This means we would like to evolve our Build step to support Script.

We decided on a staged approach, which should look as follows:

• [1] Remove the corev1.Container in favor of custom fields to continue supporting the fields we use today from corev1.Container
• [2] Move to Tekton Script.

@sbose78 @imjasonh can you make sure the above reflects what we discussed previously, thanks in advance. @adambkaplan fyi.

[adambkaplan]

Tekton seems to pass through core k8s Container object in each task step. Replacing core k8s Container with our own API means we need to be explicit about which fields we support, which is not inherently a bad thing. For instance, k8s rebases are safer because we control which new Kubernetes features are supported in the step spec.