1. Reworded the introduction to the dependency management section.   Att...

1. Reworded introduction, tried to move the document away from 'we'.  It isn't a necessarily a "bad word", but if you use it too often the documentation is an odd read.  (Who is this 'we'?  Has Gradle achieved conciousness? Maybe it has.)

2. 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.

3. 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.

4. Worked on rewording and catching language issues through the dependency management subsection of the recommended rules in the user guide.

5. 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.

6. Removed references to ancient versions.  If something was introduced in 1.4, I think it is important to mention that as a relevant fact that might help someone upgrade.   If a feature was introduced in 1.0-milestone-3, (forced deps), it seems distracting to have to mention exactly when it was introduced.