Consider plugin bindings combinations created by annotating `KongService`, `KongRoute`, `KongConsumer` and `KongConsumerGroup` objects

[pmalek]

Problem statement

644 introduced creation of KongPluginBindings based on konghq.com/plugins annotations on entities that can have plugins bound (for this specific PR Services and Routes have received support).

In order to do so, the operator needs to generate combinations of objects that should be set as targets of a plugin.

This in the operator is achieved using KongPluginBindings.

So for instance, if a plugin annotation is set on a KongRoute r1 and KongService s1 should the operator

1. Create 2 bindings: 1 binding for KongRoute and 1 for KongService
2. Create 2 bindings: 1 binding for KongRoute and KongService, and 1 for KongService
3. Create 1 binding: for KongRoute and KongService

?

KIC uses the 1st approach backed by a UT in here. This might be considered incorrect on its own but this issue does not focus on that.

This issue tracks the decision that has to be made (which might influence how KIC acts as well) whether to change the behavior described above.

659 changes the behavior that has been introduced by #644 from 3 to 1 ( to align with KIC ).

Acceptance criteria

• [ ] A decision is made on the above mentioned behavior.
  • [ ] Implementation of change of said behavior is implemented (if change was the decision).
• [ ] A decision is made whether KIC's behavior should also change (if the decision above is to change).
  • [ ] KIC issue is created (if change was the decision).