stack-controller should watch TriggerBinding and TriggerTemplate

[dacleyra]

Watch and reconcile changes/deletions to owned TriggerBinding and TriggerTemplate, as is done for Pipeline & Task to ensure integrity.

Granted, #483 needs to be fixed

[kaczyns]

We've already discussed this internally, but I'll just write it down for other's awareness. We can't fix this issue until we have a cluster scoped operator. This will probably happen when we implement #284 .

[kaczyns]

I am going to lump this into #284 for now. However I'd like to start by keeping the stack controller namespace-scoped, and just resolving the issue as it's described above, by watching objects in the other namespace. We can continue to have a discussion about whether the stack controller should be namespace scoped or cluster scoped. I am not unwilling to change my opinion on what the scoping should be. My thinking on this right now is as follows:

1. @dacleyra discovered that it is possible to have the manager cache for multiple namespaces (see https://github.com/operator-framework/operator-sdk/blob/v0.17.x/doc/user-guide.md#manager). The Kabanero/Team controller should be able to set an env var in the stack controller that tells it what to watch. In theory this should be enough to resolve this issue.
2. Having a cluster scoped Stack controller would make it impossible to start a version of the stack controller that differs from the version of the Kabanero operator, or at least would make it impossible to have two different Kabanero/Team CR instances at different versions of Kabanero. There are downstream requirements that the operator be capable of installing a certain number of previous versions of Kabanero, to allow users to upgrade at their own pace.
3. The stack controller interacts with some of the other versioned components. For example as-is you can say spec.version: "0.9.0" in your Kabanero CR instance, and you get the "0.9.0" versions of the CLI service, landing page, events operator, and stack controller. The stack controller works with these other components. If we forced the stack controller to be the version of the kabanero operator, it might not be compatible with version "0.9.0" of the events operator. This is a somewhat arbitrary line since one could say the kabanero/team controller might not be compatible with the stack controller, but that same incompatibility would apply to every versioned component and in the event it was not compatible, the kabanero/team controller would just not allow you to install that version.

So to fix this issue, the kabanero/team controller needs to set an environment variable in the stack controller deployment/pod, telling it what additional namespaces need to be watched. For the time being it's the tekton-pipelines namespace, since that's where the trigger bindings and trigger templates are. In the future it will also be the pipelinesNamespace but we're not there yet (#230).