refactor: cleanup producer code

[vmarchese]

• no need to different config flags (mongoConfig, redisConfig...). Use just --config`
• naming should be consistent to avoid redundancy since it is already namescoped
  • e.g. change gcs.GCSProducer in gcs.Producer
• move Producer interface in the producer package for consistency and isolation
• define a factory for producer instead of different createXXX methods
• change emitter.Emitter.Initialize sequence of if using factory with a producer factory map
  • e.g. producerFactory["mongodb"].createProducer()

[vmarchese]

@ugol
In this branch

• added factory in emitters to simplify the producers creation
• changed the various --xxxConfig in --producerConfig
• changed the Redis configuration to add the TTL in the config file to uniform the factory interface

In producers/factory.go there is an (unused for now) factory and the Producer interface. The Factory is filled with factory func by the init method that should go in every concrete impl (see https://github.com/ugol/jr/blob/161-refactor-cleanup-producer-code/pkg/producers/http/init.go for an example, unused for now)
It is true that that best practices say that "Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values" but I believe that it depends on how you structure the code. If you move everything that is not "exportable" to internal and use the pkg to export producers than I think it is better to have a producers.Producer interface (like io.Closer) in a separate package the defines the behaviour (someone could use JR as a framework and just implement his own producer somewhere else.
Moreover, if we leave the Producer interface in the emitter package the Factory must go there as well to avoid circular references

See the crypto and the aes or cipher std packages for an example
See also this