Avoid use of `afterEvaluate`

[big-guy]

This can wait until later, but we should be judicious in the use of afterEvaluate. This has been good so far.

[bmuschko]

You may want to review this again. Maybe I am overly cautious with the remaining use of afterEvaluate. Potentially we can avoid some of it through additional Provider API usage.

[big-guy]

I see three remaining afterEvaluates:

https://github.com/gradle/play/blob/2e12a26ac1c2ad3be978bdbabea2d856af7d189f/src/main/java/com/lightbend/play/plugins/PlayTwirlPlugin.java#L39-L43

I think we could try removing this entirely and making it a documentation issue. If you use Java imports, you have to add a dependency.

https://github.com/gradle/play/blob/2e12a26ac1c2ad3be978bdbabea2d856af7d189f/src/main/java/com/lightbend/play/plugins/PlayTestPlugin.java#L31-L57

I think this could be slimmed down a bit. I think if we do #55, a bulk of the configuration might go away and just leave us with the source/target compatibility properties. Everything else should be able to come from the default Scala plugin.

https://github.com/gradle/play/blob/2e12a26ac1c2ad3be978bdbabea2d856af7d189f/src/main/java/com/lightbend/play/plugins/PlayApplicationPlugin.java#L68-L74

I think this is similar to the one above this. If we used the regular configurations most of the configuration would go away for the tasks, but we'd still need the juggling that happens with the platform and deriving dependencies from it.

[bmuschko]

I think at least 1. would be a little awkward as you'd either have to know the full dependency notation with its variant or use the method that can prepare it for you.

dependencies {
    play or compile extensions.play.platform.getDependencyNotation('play-java').get()
}