Refactor controller queue logic

[mikkeloscar]

This is a fundamental refactoring of the controller watch/queue logic with the intention of making it more efficient.

So far the stackset-controller worked roughly like this:

1. watch for stackset changes (via informer)
2. For each change emit an event
3. For each event maintain a central table of active stacksets
4. Every internal (2s)
5. Collect all stackset related resources and build a table of stacksets to child resources (stackset container)
6. In parallel reconcile all stackset containers (concurrency limited by number of "workers")

With this change it now works more like this:

1. watch for stackset changes (via informer) (also watch for all possible child resource types via informer)
2. For each change update a workqueue (using standard client-go workqueue pattern) - The queue just has StackSet Namespace/name as key, if there is a change to a child resource of a StackSet the stackSet namespace/name is resolved and the queue is updated, essentially triggering a new reconcilication no matter which child resource changed.
3. Workers go through the queue and for each item
4. Collect all stackset related resources via local informer caches and build a stackset container
5. Reconcile the stackset container

TODO

• Validate that tests/e2e works as usual
• Validate speed of new implementation
• Remove old implementation