Fix support for TestSwarm on SpecialJavaScriptTest/qunit

Fix support for TestSwarm on SpecialJavaScriptTest/qunit

So far we've still been using ./tests/qunit/index.html in TestSwarm, today I've tested locally
to submit a url to SpecialJavaScriptTest instead and made a bunch of browsers join my swarm,
quite a few problems popped up. This commit fixes those issues so that we can actually use
SpecialJavaScriptTest in TestSwarm.

* Add QUnit configuration variable for TestSwarm's inject.js

  In order to use TestSwarm, the urls that TestSwarm loads in clients that has
  the QUnit test suite running on it need to include a little javascript.
  This inject.js registers hooks with QUnit to listen for when the test suite finishes
  and contacts the parent window (TestSwarm loads the qunit test suite url in an iframe)
  to submit the results. Previously I included a copy of TestSwarm's inject.js in
  ./tests/qunit/data and in our testrunner.js a relative link to that.
  However this is currently breaking because it is an outdated version. Updating brings
  no good since someone else might use their own TestSwarm would could still run on an old
  version etc. The TestSwarm submitted too always expects that it's own inject.js is used,
  not some snapshot copy. I've removed the copy of it in MediaWiki and instead added a
  configuration option to point to wherever the you want is located.

  Also, since the old static index.html version of the unit test can't retrieve PHP based
  content, this means TestSwarm submissions through the old static index.html are no longer
  supported. Only through the new Special:JavaScriptTest from now on. I'll probably remove
  the whole index.html soon-ish as it's getting quite annoying to maintain all that by hand,
  and it's been superseded in everywhere imaginable now anyway. Even not used anymore by
  intergration.mediawiki.org because that's been quiet since the Git-switchover.., and when
  we update it, we can update it to point to the new SpecialPage instead.

* OutputPage::allowClickjacking() on SpecialJavaScriptTest/qunit.

  When initially testing the TestSwarm setup to submit SpecialJavaScriptTest/qunit urls
  (instead of the old ./tests/qunit/index.html) it was failing due to an iframe DENY.
  This was a bit odd since `$wgBreakFrames = false;` by default, and although
  `$wgEditPageFrameOptions = 'DENY';` by default, it wasn't obvious at all that that value
  ("DENY") is used for all OutputPages by default (as supposed to just action=edit and the
  like). This is because OutputPage has  mPreventClickjacking=true by default and when it's
  true-ish it uses $wgEditPageFrameOptions for the X-Frame-Options.

* 'position' => true; for the mediawiki.tests.qunit.suites module.

  QUnit has a hook for "done". Which is called when QUnit.start() is called and all queued tests
  have been executed. QUnit.start() is automatically called on window.onload by QUnit.

  TestSwarm uses QUnit's hook system to hook into the QUnit "done" event, and at that point
  takes the stats, submits them to TestSwarm and go on with the next job.

  When testing locally, I got semi-random failures reporting that only 0/0 tests were
  successfully ran in IE6. This is because when QUnit.start (and consequently QUnit.done)
  are first called, apparently no test suites had finished downloading and/or execution yet
  (the bottom queue is asynchronous, and doesn't postpone domready nor window.onload).

  When normally viewing Special:JavaScriptTest/qunit this doesn't break anything, because if
  QUnit start/done is in the past and another module(), test(), or equal() etc. is called it just
  picks up again and adds more results to the page and calls QUnit.done() again.
  However in the case of the TestSwarm embed, it submits the results after the first done() and
  cleans up the iframe. So I'm making mediawiki.tests.qunit.suites a blocking module instead, so
  that there will only be one QUnit.start/done and that's the one that TestSwarm gets and after
  which TestSwarm can safely garbage the iframe.

  This means that basically all test suite modules and the original modules they are testing will
  be loaded from the head. Shouldn't have any side effects, but might cause minor breakage in
  future in modules that badly assume they're being put on the bottom.
  I'm not considering that a bug in the test, it'll just help catch that bad code sooner :),
  it's a test suite after all.

(Yay, my first Git commit to MediaWiki core)

Change-Id: I83f83377f2183b6deb4e901af602ac9a5628558b