Replace use of convention mappings with PropertyState and Provider

[wilkinsona]

We current use Gradle's support for convention mappings in a few places in the Gradle plugin. This is an internal API so it'd be nice to move off it. Gradle 4.0 introduced PropertyState and Provider that can be used to achieve the same end result.

I have some reservations about the PropertyState and Provider APIs in their current form. As far as I can tell you have to be comfortable with losing some type safety. For example, if you want to have a List<String> property, you cannot have a PropertyState<List<String>> and Provider<List<String>> for it. Instead, have to make do with PropertyState<List> and Provider<List> and hope for the best.

Convention mappings have a similar lack of type safety but it doesn't leak into a task's own API (unlike setThings(Provider<List> thingsProvider) would for example). I also believe that convention mappings benefit from some of Groovy's type coercion and property states do not.

We may well decide that continuing to use convention mappings is the least bad option here.

[wilkinsona]

There's a Gradle issue that relates to this. Thanks to some pointers from @eskatos, I now realise that things aren't as bad as I had feared.

The API for the Provider side of things is fine. You can do this:

Provider<List<String>> provider = project.provider(() -> Arrays.asList("a", "b", "c"));

This is important as user code may want to create such a Provider and we want to be able to offer setters that take Provider<List<String>> and the like.

The PropertyState side of things is a bit more awkward, but the problem can be worked around by casting:

PropertyState<List<String>> listState = (PropertyState<List<String>>) (Object) project
        .property(List.class);

This isn't great, but it'll be hidden in the plugin's internals and allow the API to use Provider<List<String>> which is what really matters.