AL-553 - Added Config class to use in lieu of constants

[TeslaDethray]

The old method of setting configurabls constnats necessitated the creation of a Configurator object, properly belonging to WP-CLI's dispatcher, to make use of Terminus' configuration. I've separated the Terminus Config from the Configurator and ended the widespread use of constants in favor of static methods from the Config class.

Also:

• Removed a whole lot of duplicative code
• Standardized the format of models and collections

[pantheon-mentionbot]

@TeslaDethray, thanks for your PR! By analyzing the blame information on this pull request, we identified @bensheldon and @joshkoenig to be potential reviewers

[greg-1-anderson]

@TeslaDethray Looks like you need a mkdir somewhere around here. There may be other places; might be convenient to add mkdir as a side effect of Config::get('cache_dir'), but better practice to ensure the directory is created as needed prior to writing.

[coveralls]

Coverage increased (+0.6%) to 18.362% when pulling 30b8cad on addition/10_models into c2538bf on master.

[TeslaDethray]

Should be singular.

[TeslaDethray]

Did that function disappear or were the inline docs just duplicated?

[coveralls]

Coverage increased (+0.5%) to 18.334% when pulling d588402 on addition/10_models into c2538bf on master.

[ronan]

I'm a big supporter of the concept but have a couple of notes:

1. We should consider trying to use standard Symfony components as much as possible rather than building our own. This will mean less code to maintain and better interoperability with other components: http://symfony.com/doc/current/components/config.html

2. I would rather see some sort of dependency injection used for configuration rather than the global access pattern: $config = Config::getAll();

Taken together, the logical conclusion of this would be to make sure all of our code works with the Symfony DI container: http://symfony.com/doc/current/components/dependency_injection.html
Doing so will take some work (and some rethinking) but ultimately things will get a lot easier with config, dependency management, dependency injection all handled by a pretty robust and trusted component.

Given how much there is to do in this refactor and that either of these items could send us down a rabbit-hole, I'm comfortable endorsing this PR as-is though.

+1

[dustinleblanc]

@ronan there are a few other good DI containers out there, Symfony isn't the only option. League's container can work really well.

[greg-1-anderson]

@dustinleblanc I was about to suggest league/container as well! I find it much nicer to work with than the Symfony DI container.

Also, I have been meaning to write a config system for Robo based on the Symfony Config class for some time. I agree with Ronan's conclusion that doing that at this point would be a rabbit-hole (said after already merged :P )