Remove OutputFormatterInterface::getName

[dbrumann]

See #801 for reference

This is more difficult than CollectorInterface, because we currently load config dynamically based on which collector is used. This must be moved inside the container.

I think we can use a similar approach. As far as I can tell we don't really need the OutputFormatterFactory anymore, because we only support 1 formatter during analysis anyway. That means, we can inject the configured formatter into the command instead. That also means all the configuration logic needs to move into the container building process somehow for everything that we do not pass as command option. Command options are evaluated after the container and therefore the OutputFormatter is built. In other words, we might still need to pass some config to the formatter at runtime.

My initial idea is, that each formatter will be fully configured in the container, e.g. by adding depfile parameters as arguments to the service definition and making the other formatters optional by using ->nullOnInvalid() in case their (constructor) config is not provided. Meaning, we only need to pass arguments to the formatter we actually want to use.