Better way to handle include configuration

[Barteks2x]

Instead of reinventing resolving the configuration manually, just resolve it and actually make the remapJar task depend on the configuration. Depending on the configuration ensures that gradle runs the subproject tasks that generate the outputs. This wouldn't work with the dependencies being specified as inputs.

This handles project dependencies correctly, including specifying a target configuration, attributes and using artifact transforms.

I'm not sure which branch I should target, so it's on 1.0.

This is technically a breaking change because project dependencies may be included slightly differently in nontrivial cases.

I don't think the visited set is really needed (what would it be for?) but I can put it back in if it's for some reason required.

[Juuxel]

This is technically a breaking change because project dependencies may be included slightly differently in nontrivial cases.

Also a breaking change since it removes an API method (I think tasks are API classes?): RemapJarTask.getNestedJars.

[modmuss50]

Yes, this is a major breaking change. getNestedJars is used quite a bit.

[Barteks2x]

This PR was made because we thought we needed it as it broke some things for us, but we ended up doing things in a different way that makes it unnecessary and I just don't have the motivation and time to try to make it work without being a breaking change.

I'm still fairly certain this is in fact the correct way to handle include configuration by how gradle works.