The initial goal was to write a test to make sure that build-tools can
be used by plugin authors outside of our build. Example projects seemed
like a good fit rather than writing dummy ones just for the test.

- Add an integration test based on testKit to build the example plugins
like stand alone projects
- the tests injects the snapshots repo right now
   - an alternative would be to inject the last release version to cause
     dependency resolution against that. It wouldn't be 100% realistic
     as we would build using old dependencies and current build-tools
     which never happens in practice, but it would result in fewer
     moving parts.
   - the snapshots does cover more ground at the cost of some confusion
     as these are delayed from the current build, so any new issues will
     introduced will surface in the next build only.
- there are also some changes for making it easier to copy these
examples, but it won't quite work yet, e.x. applying the plugin
only works because of testKit. Applying the project like this won't work.
It might work if we add a version number and publish it to the
Gradle plugin portal.
- testKit can have the gradle version configured, so it would be easy to
add similar tests for different Gradle versions.
- The tests are failing due to 2 reasons:
   - elasticsearch-nio is not published. I am looking to fix this.
   - `painless-whitelist` references `project(':modules:lang-painless')`
      so this isn't really an example that will work stand-alone.
      Not sure what we should do about this one? Not test it or publish
      the plugin jar ?

…-build

Will publish everything that has publishing configured to a local repo