[BEAM-3249] Allow for re-use of dependencies within other projects by placing them within build_rules.gradle

[lukecwik]

---

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a JIRA issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes.
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
• Write a pull request description that is detailed enough to understand:
  • What the pull request does
  • Why it does it
  • How it does it
  • Why this approach
• Each commit in the pull request should have a meaningful subject line and body.
• Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

[kennknowles]

Just drive-by comment: A similar action that would make the project more idiomatic and result in fewer moving pieces would be to move the nature defs from build_rules.gradle into build.gradle (thus deleting build_rules.gradle). It would also make the code clearer since projects would be passed explicitly instead of implicitly global.

[lukecwik]

Kenn, Gradle doesn't work as you expect in this regard. Moving things out of build_rules.gradle into build.gradle would use the root project since it is in scope. This is why we are using apply from within each project so that when we define things like applyJavaNature, it uses the current project and its context.