run-tests: write JSON reports to output dir

run-tests: write test times to output dir

run-tests: allow specifying an output dir to write .errs to I'm trying to use run-tests.py on a read-only file system. This series allows that to happen.

run-tests: add information about skipped tests to XUnit output The XUnit spec supports skipped tests.

run-tests: wrap failures in an XUnit 'failure' element This is closer to what most XUnit consumers can understand.

discovery: log discovery result in non-trivial cases We log the discovery summary, the number of roundtrips and the elapsed time. This is useful to understand where slow push might come from when lloking at the blackbox.

discovery: include timing in the debug output Having such date easily available is useful. It also prepare the inclusion of some discovery related data in blackbox.

tests: remove sys.executable from "required tools" In practice this doesn't appear to have been true for some time - we reference Python using the $PYTHON variable in all the tests now (which we have to for PyPy and Python 3), and I've been using ~/.../python.exe to test with tip of the cpython 3.6 release branch while working on manifest tests in Python 3 and everything seems to be just fine. The only real observable difference from this change is that I stop getting a warning about python.exe not being a thing on $PATH, which seems like an improvement.

perfbranchmap: add an option to purge the revbranch cache The perf extension needs to be able to reflect this reality too. (eg: 4s vs 60s on a Million-ish revisions repository).

push: add a way to allow concurrent pushes on unrelated heads Client has a mechanism for the server to check that nothing changed server side since the client prepared a push. That check is wide and any head changed on the server will lead to an aborted push. We introduce a way for the client to send a less strict checking. That logic will check that no heads impacted by the push have been affected. If other unrelated heads (including named branches heads) have been affected, the push will proceed. This is very helpful for repositories with high developers traffic on different heads, a common setup. That behavior is currently controlled by an experimental option. The config should live in the "server" section but bike-shedding of the name will happen in the next changesets. Servers advertise this capability through a new bundle2 capability 'checkeads', using the value 'related'. The 'test-push-race.t' is updated to check that new capabilities on the documented cases.