Create minimal functional tests of command output to test Output refactoring

These look good to me. I added an @group docker for the test that didnt work in an env without docker running, and tweaked a broken thing that phpunit was complaining about (https://3v4l.org/vVgKH), otherwise we have a beginning. I'll have one more sanity check from somebody, and then we can merge this into dev. Almost RTBC?

Just look at some of those tests and they look really reasonable.

I have some test failures when I run them locally, when I run them inside the VM, but don't feel blocked on them:

Time: 1.33 minutes, Memory: 13.75Mb

There were 3 failures:

1) DrupalCI\Tests\Console\Command\Config\ConfigLoadCommandTest::testLoad
Failed asserting that 'You chose configset: /home/vagrant/.drupalci/configs/foof
This will wipe out your current DrupalCI defaults and replace them with the values from the foof configset.
Are you sure you wish to continue? (y/n) Action cancelled.
' matches PCRE pattern "`Unable to load configset. The specified configset does not exist.`".

/home/vagrant/drupalci_testbot/tests/DrupalCI/Tests/Console/Command/Config/ConfigLoadCommandTest.php:20

2) DrupalCI\Tests\Console\Command\Config\ConfigResetCommandTest::testReset
Failed asserting that 'This action will delete the foof configuration set.
Do you wish to continue? (yes/no) ' matches PCRE pattern "`The 'foof' configuration set does not exist.`".

/home/vagrant/drupalci_testbot/tests/DrupalCI/Tests/Console/Command/Config/ConfigResetCommandTest.php:19

3) DrupalCI\Tests\Console\Command\Config\ConfigSaveCommandTest::testSave
Failed asserting that 'The foof config set already exists.
Continuing will overwrite the existing file with the current configuration values.
Are you sure you wish to continue? (yes/no) Action cancelled.
' matches PCRE pattern "`Unable to save an empty configuration set.`".

/home/vagrant/drupalci_testbot/tests/DrupalCI/Tests/Console/Command/Config/ConfigSaveCommandTest.php:19

LGTM. I'd say we can roll this into dev. Im not necessarily saying this is enough tests to start ripping out the Output:: stuff, but its probably good enough to prove that what we're removing and replacing it with will work, but it wont reveal if we forget to replace stuff. Then again, global search is our friend there.

Fire at will.

Only runs properly the first time ... once you run the tests once, config:save creates a 'foof' configset; and config:load asserts that 'foof' doesn't exist.

Yes, this is a dependency on the configuration setup ... but when you start with a clean slate, and do nothing except run the tests twice, we should expect both iterations to pass. :)

Resolved the configuration setup issues for the full set of 'config' tests. Key fixes were to add interaction input for tests where the configuration setup might cause an interactive prompt, and modify the regex to check for both cases (configuration present or not).

Ooops ... yep, that should come out.

That was simply a way to avoid having to type out the individual class names and paths ... i.e. "phpunit --group failing", and moving the annotation from class to class as I worked through them.

I think a @failing tag is fine in the repo. There are instances where one of us might want to write a test for a known bug, say run a contrib test that doesnt have tests, and commit it, and somebody else could fix that test...

As for the config changes, these will work for now. Eventually we're going to want to isolate those tests from the developers local environment, as in make the .drupalci config directory a configurable option, such that the tests use .drupalci-test. Then we can have distinct tests that exercise different parts of the process - each test would empty the config directory, and perhaps set it into a state with a fixture. So instead of having logic in the test that allows for multiple responses, depending on the state of the .drupalci config dir, we have distinct tests that exercise both of those situations.

But best doesnt need to block better here. Merged into dev and pushed.

Good logic on the 'failing' tag ... but in this case, it's no longer failing. ;)