Introduce a framework for components lifecycle

[yurishkuro]

The main functions of query/collector/standalone have a lot of duplication due to the way various components are configured, initialized, used. We could do better.

At minimum, all components that provide CLI flags and initialization from Viper could be written as plugin.Configurable instances (from #625) which will reduce the boilerplate code by 30%. Right now every component is called 3 times: to AddFlags, to instantiate the actual Options struct, and to InitFromViper. A simple change is to instantiate them all as objects first, then add them all to a list so that AddFlags and InitFromViper can be done on the collection.

A possible extension is to look into some dependency injection frameworks like https://github.com/uber-go/fx.

[jpkrohling]

I think you did something in this direction as part of #1442, but would still be nice to go one step further and adopt a dependency injection framework. This would also probably help with #355.