(ops#878) phpunit.xml.dist - Prevent conflict in WordPress E2E with "stderr=true"

Before
------

When running any of the end-to-end (E2E) tests on CiviCRM-WordPress, the output is polluted with these warnings:

```
[bknix-dfl:~/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm] phpunit5 tests/phpunit/E2E/Cache/FastArrayDecoratorTest.php
PHPUnit 5.7.27 by Sebastian Bergmann and contributors.

PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/Util/Printer.php:110) in /Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm.php on line 346
PHP Stack trace:
PHP   1. {main}() /Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar:0
PHP   2. PHPUnit_TextUI_Command::main() /Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar:598
PHP   3. PHPUnit_TextUI_Command->run() phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/TextUI/Command.php:116
PHP   4. PHPUnit_TextUI_TestRunner->doRun() phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/TextUI/Command.php:186
PHP   5. PHPUnit_Framework_TestSuite->run() phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/TextUI/TestRunner.php:517
PHP   6. call_user_func:{phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/Framework/TestSuite.php:679}() phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/Framework/TestSuite.php:679
PHP   7. E2E_Cache_CacheTestCase::setUpBeforeClass() phar:///Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar/phpunit/Framework/TestSuite.php:679
PHP   8. CRM_Utils_System::loadBootStrap() /Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm/tests/phpunit/E2E/Cache/CacheTestCase.php:43
PHP   9. CRM_Utils_System_WordPress->loadBootStrap() /Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm/CRM/Utils/System.php:1477
PHP  10. require_once() /Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/WordPress.php:479
PHP  11. require_once() /Users/totten/bknix/build/wpmaster/wp-load.php:37
PHP  12. require_once() /Users/totten/bknix/build/wpmaster/wp-config.php:94
PHP  13. do_action() /Users/totten/bknix/build/wpmaster/wp-settings.php:325
PHP  14. WP_Hook->do_action() /Users/totten/bknix/build/wpmaster/wp-includes/plugin.php:453
PHP  15. WP_Hook->apply_filters() /Users/totten/bknix/build/wpmaster/wp-includes/class-wp-hook.php:323
PHP  16. call_user_func_array:{/Users/totten/bknix/build/wpmaster/wp-includes/class-wp-hook.php:298}() /Users/totten/bknix/build/wpmaster/wp-includes/class-wp-hook.php:298
PHP  17. CiviCRM_For_WordPress->setup_instance() /Users/totten/bknix/build/wpmaster/wp-includes/class-wp-hook.php:298
PHP  18. session_start() /Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm.php:346
```

After
-----

The session_start warnings are no longer generated..

Comments
--------

The problem appears to be this:

1. When PHPUnit starts, it puts some messages on STDOUT.
2. When the specific tests/test-suites are setup, they bootstrap WordPress, and WordPress tries to setup a session, which requires setting some headers
3. But we've already started writing STDOUT, and we can't send any headers.

The patch is based on suggestion [a StackExchange
discussion](https://stackoverflow.com/questions/23270650/cannot-send-session-cookie-headers-already-sent-phpunit-laravel/38045422)
-- basically, by setting the `stderr` option (which is documented lightly in the cli `phpunit5 --help`), we prevent
step 1 above -- because PHPUnit now prints messages to STDERR instead of STDOUT.

The only concern (`r-tech`) would be...  is there anything in our ecosystem which depends on piping information from
PHPUnit's STDOUT?  Obviously, I can't speak for third-parties, but the general pattern in `civicrm.org` CI scripts
(e.g.  `civi-test-run`) is to evaluate PHPUnit output through a mix of (1) exit-codes and (2) JUnit files.  In which case...
it doesn't matter if PHPUnit writes messages to STDERR or STDOUT.

I'd suggest paying close attention to the console output for the PR-test here; if that's good, then we're probably OK.

phpunit.xml.dist

@@ -7,6 +7,7 @@
          processIsolation="false"
          stopOnFailure="false"
          syntaxCheck="false"
+         stderr="true"
          beStrictAboutTestsThatDoNotTestAnything="false"
          bootstrap="tests/phpunit/CiviTest/bootstrap.php"
 >