Instantiate logging depending on environment

[gbirke]

Feature: https://phabricator.wikimedia.org/T200676

[gbirke]

@timEulitz @tzhelyazkova I'm unsure about some parts of the refactoring:

• Is is clear enough how to set APP_ENV especially when running console commands, or should we add documentation?
• Is injecting services after-the-fact into FunFunFactory ok or should we rather have a EnvironmentFactory interface and instantiate FunFunFactory with that, using it internally like with the ChoiceFactory? Existing FunFunFactory interface could be left as-is and environment-dependent instances could be passed on to EnvironmentFactory.

[JeroenDeDauw]

double space omg what does it mean?

[timEulitz]

Is is clear enough how to set APP_ENV especially when running console commands, or should we add documentation?

It's clear to me but I don't think it would hurt to leave a short sentence about that (also with regards to the fact that we will be getting an intern soonish and that there will be other people in the future who might not know).

Is injecting services after-the-fact into FunFunFactory ok or should we rather have a EnvironmentFactory interface and instantiate FunFunFactory with that, using it internally like with the ChoiceFactory?

I think overall the EnvironmentFactory you propose would make the code better to read because you can more easily point at a named place in the code in which environment configurations are applied rather than a couple of random lines in the index files. You can also probably get rid of hard-coding the dev string value in the two entry files and move it to that class.

The thing that bugs me the most about it is that a Factory builds another Factory which seems very weird and kinda convoluted to me, but overall I think in this instance it's actually okay.