Can add Gradle Plugin Portal at any point in the repository list

[oehme]

Motivation

When the user defines the list of plugin repositories, he expects them to be queried in the given order. This should also apply to the Gradle Plugin Portal.

Proposed Change

Instead of always adding the Plugin Portal as the last resolver in the list, add a gradePluginPortal() method to the pluginRepositories block which allows users to add the Plugin Portal resolver at any point between their custom repositories.

Code Review

• [] Does the change work?
  • [] Try out the feature, executing it like a end-user would.
  • [] Check corner cases and try to break it in various ways.
  • [] Are the error messages informative?
• [] Is the change sufficiently tested?
  • [] Are there appropriate levels of unit & integration tests?
  • [] Do the tests indicate what they are actually testing?
  • [] Are the tests in the right location?
  • [] Can new tests be consolidated with any existing tests?
• [] Does it change the public API?
  • [] Has @Incubating been used appropriately?
  • [] Does it preserve backward compatibility?
• [] Is it sufficiently documented?
  • [] Is the user guide documentation in the best location?
  • [] Is the user guide documentation clear and informative?
  • [] If there should be samples, are they helpful and tested appropriately?
  • [] Is there sufficient API/DSL documentation?
  • [] Is the API/DSL documentation clear and informative?
  • [] Do the release notes clearly convey the value of the feature?
  • [] Do the release notes explain the feature and link to more documentation?
• [] Is it implemented well?
  • [] Does it minimize surface area (particularly public)?
  • [] Does it follow our coding conventions? (note that we don't have coding conventions formalized but it's something to keep in mind)
  • [] Does it use appropriate data structures?
  • [] Does it minimize potential for invalid states?
  • [] Does it suitably reuse existing infrastructure?
  • [] Does it suitably consider concurrency?
  • [] Does it suitably consider failure modes?
  • [] Does it suitably consider performance?
  • [] Does it introduce new types or move existing ones? Are they located in the appropriate package? (e.g. internal classes in internal packages)

[oehme]

See gradle/gradle@b42c9fa

[eljobe]

This change looks good to me. I haven't tried it out yet, but the test coverage and all the code look good. I'll start trying it out a little later.