add strategy to get gradle commitid from release branch in non gradle builds.
only set `sonar.working.directory` for parent project (it's a global property)
Some spec updates.
Reworked the multiple outputs spec based on discussions on the dev list.
REVIEW-1157 added coverage for the configuration on demand message.
REVIEW-1157 Tidy up in the registries - when configuration on demand is on slightly different pipeline of actions is created.
Updated the tooling api test so that it uses 1.0-milestone-5+ tooling api version.
Added new story to the COD spec. It's about handling tasks that are coupled with 'external' projects (e.g. 'tasks' task includes information from subprojects).
REVIEW-1162 Added new story to the COD spec. It's about handling tasks that are coupled with 'external' projects (e.g. 'tasks' task includes information from subprojects).
REVIEW-1167 Added a test case to the configuration on demand integ test
Fixed one of the unit tests.
REVIEW-1179 Tidy up in the dependency graph builder. Avoided creation of redundant selector.
Made the tone of incubating feature in the user guide slightly more positive. In the 'Incubating state' section switched order of 2 paragraphs.
REVIEW-1200 Mentioned in few more places that configuration on demand is an incubating feature.
REVIEW-1196 Updated the spec.
REVIEW-1157 Tidy up in the build configuring logic that deals with configuration on demand mode and with regular mode. Simplified the implementation.
1. Reworded the introduction to the dependency management section.   Attempted to simplify and move away from 'we'.   It isn't that I suggest avoiding 'we' entirely, I use it myself, but if you use 'we' too much in a user manual it starts to sound a bit 'cultish'.

2. Filed out the intro paragraph a bit

3. Rewrote most of the introduction.  The itemized list wasn't really a list, so I've changed it to be a bit more obvious that this is listing major highlights of the feature.   I've also added some explanation at the end of the introduction to reinforce the core idea of Gradle:  We support strong conventions, but we give you the freedom to innovate how you see fit.

4. More polish to the introduction.   One important change was to move the compatibility line items for Gradle to the end of the highlighted feature list.  I think that Gradle needs to move away from comparing itself to Maven as a leading argument.  This might have made more sense in the beginning of the project, but Gradle is now able to stand on its own merits without having to remind the reader of this other build tool.

5. Worked on rewording and catching language issues through the dependency management subsection of the recommended rules in the user guide.

6. Finished rewording of the intro rules section

7. Reordered sections in the dependency management introduction.   The "Dependency Management in Java" was not appropriate where it was in the original document because it fell at the end of a list of Rules.   I've also added a section into the introduction that places special emphasis on the usefulness of Gradle during a build migration.
mention scala IDE integration
mention Scala related improvements to IDEA plugin
first cut at a spec for implicit coercion to File values.