Consume BotKube configuration from values.yaml and commands

[mszostok]

Description

The configuration changes made via @BotKube commands are not persisted. As a result, when the Pod is restarted, we lost all changes.

In K8s world, the Pod restarts are a normal thing, and we should be resistant to it.

Acceptance Criteria

1. Research what's the best option here from UX and maintenance point of view. [1MD]
2. @Botkube notifier stop/start changes are persisted
3. @BotKube filters disable/enable changes are persisted
4. Persist source bindings
   • They override bindings from the configuration
5. Support configuration for notifier, filter, source bindings during Helm install/upgrade and @BotKube commands
6. We don't add new features besides the persistency. For example, the @BotKube filters disable/enable command still can work globally.
7. E2E Tests

• consider: ensure @Botkube notify stop/start doesn't restart the pod/
• kill the pod and see whether notifier config / filter config is saved

define the filters configuration under filters.kubernetes in values.yaml

Steps to reproduce

1. Install BotKube inside cluster
2. Run @BotKube notifier stop
3. Kill the pod, e.g. kubectl delete po -l app=botkube
4. See that you get a new message on channel:

   ...and now my watch begins for cluster 'gke' ! ⚔️

Notes

If we use the existing one with global configuration, the Pod will be restarted, which is not needed because of that we can store the data in dedicated ConfigMap.