Move to Conditions instead of Status in the BuildRun

[qu1queee]

Idea:

From previous community discussions, we would like to move out from having a Status on the Buildrun in favour of Conditions. This doc explains in detail why Conditions are a good practice in Kubernetes. Also, the Tekton TaskRun relies only on Conditions and their different fields are explained in here https://github.com/tektoncd/pipeline/blob/master/docs/taskruns.md#monitoring-execution-status

[gabemontero]

Some cross referencing

• previously suggested in WIP: Retrieve build stage status from the build run #280 ... specifically the thread starting with WIP: Retrieve build stage status from the build run #280 (comment) , where @qu1queee agreed to take on opening an issue in WIP: Retrieve build stage status from the build run #280 (comment)
• that PR stemmed from attempting to address [discuss] Improve CR Status Feedback #67

[qu1queee]

Updates on this:

• In general this requires a 4 step process. As mentioned in November 9th Community Meeting  #469 , here is the proposal doc https://drive.google.com/file/d/1yK4aNrzDm0DqUagtxsqWIA8Lc_MTPqQS/view?usp=sharing
• Step one is to allow the CRDs to operate on Conditions, this is addressed via Add conditions pkg to support Build CRDs to operate on Conditions #475
• Step two, is to add the logic in the BuildRun controller to update the Conditions field. This should be using a single Condition of the type Succeeded, on the same way the Tekton TaskRun does it.
• Step three is to enhance the BuildRun Status fields to provide more insights in case of errors, e.g. new fields (doc describes this in detail)
• Step four is a migration plan to avoid breaking changes.

Once both steps are done, we can close this issue.

[qu1queee]

we are working now in step 2, to make the BuildRun to use the Conditions, wip branch is https://github.com/qu1queee/build/tree/br_conditions_imp, fyi