GRADLE-2650: always set http.keepAlive = "true" to work around bugs in HttpClient-4.2.2
REVIEW-935 - extracted TestOutputSerializer out of TestReportDataCollector and use this instead of AbstractTestResultProvider in each TestResultProvider implementation.
Removed unused constructor.
fixing grammar in sourceset.output doc
Add pullrequest 126 to the release notes.
Put the JVM 5 daemon arg quoting back in because something is breaking down without it.

Needs further investigation.
Basic support for PMD 5.0+. Highly dependent on the toolVersion since the
ant tasks have changed between 4.3 and 5.0
Changed how pmd version is determined in the pmd task. Added integration
test and rule set default values now is dependent on version
Updated targetjdk handling in pmd since the property is nonexistent in pmd 5.0
Remove some redundancy in PmdTask (pull request 125)
Add pull request 125 to release notes.
Added a contributor (maven conversion bug pull request) to the release notes page.
Added some more design musings for the configuration-on-demand
Updated docs on configuration on demand.
Small rename job.
Tightened some coverage around configuration on demand. Fixed small problem in the InProcessGradleExecuter (command line args needs to be parsed before processing the gradle properties).
Added a bit of coverage to the parallel integ test.
Added gradle property 'org.gradle.parallel' for parallel execution.

1. I decided to only add org.gradle.parallel for now (avoid parallel.threads). It's because it feels awkward to configure exact number of threads in the gradle.properties - Gradle should figure out the optimal number for the user. Supporting both 'org.gradle.parallel' and 'org.gradle.parallel.threads' also means that we need to code some rules for the scenario when the user specifies both options (e.g. some combinations are mutually exclusive).
2. Added startParameter.isParallelThreadCountConfigured() method. This is a bit awkward but that was the simplest reasonable solution I came up with. (btw. We need to make StartParameter an interface). There's some complexity around the start parameter & gradle properties processing:
a. First we need to parse / convert the command line arguments because they contain information needed for gradle properties parsing (e.g. search upwards, directory, user home, etc.)
b. then we need to pull data from gradle properties and update the start parameter accordingly. However, the command line arguments should generally win over the gradle properties. So gradle properties can only update the start parameter *if* start parameter was not explicitly configured with given property.
3. The StartParameter.newInstance() method seems to be incorrect (the source and target instances share some collections). Should I fix it?

I'm open to discussion how to solve above better.
Documented new Gradle property (org.gradle.parallel).
Some minor tweaks to a couple of dependency resolution int tests.