Fix deprecation warnings in Gradle build

[ghale]

With the single project lock work, we have surfaced some instances in the gradle build where we are doing cross-project configuration resolution and are throwing deprecation warnings. We should investigate where we're doing this and fix them.

[ghale]

Looks like the deprecations fall into three usages that are all the same sort of thing:

• checkBinaryCompatibility adds configurations from other projects directly to its inputs here (see https://github.com/gradle/gradle/pull/7407)
• generateGradleApiPackageList adds configurations from other projects directly to its inputs here (see https://github.com/gradle/gradle/pull/7433)
• javadocAll adds file collections from other projects (that are backed by configurations) directly to its inputs here (see https://github.com/gradle/gradle/pull/7450)

[ghale]

One more (same sort of thing):

[lacasseio]

checkBinaryCompatibility is fixed in this PR: https://github.com/gradle/gradle/pull/7407

[big-guy]

@lacasseio I merged PR 7407 above into master, but we probably want to put these all on release first so we don't have any surprises with a 5.0 nightly

[lacasseio]

generateGradleApiPackageList is fixed in this PR: https://github.com/gradle/gradle/pull/7433

[lacasseio]

I will cherry-pick the commit inside release.

[big-guy]

@lacasseio I cherry-picked it already, should have told you when we were chatting

[lacasseio]

javadocAll is fixed in this PR: https://github.com/gradle/gradle/pull/7450

[lacasseio]

apiMetadata is fixed in this PR: https://github.com/gradle/gradle/pull/7451

[big-guy]

I was about to close this, but I found two more instances:

• IntTestImagePlugin is doing something strange with the root project too. https://e.grdev.net/s/y3yykuqmt3m5y/deprecations
• distributions.gradle https://e.grdev.net/s/ejnufwx2hap3g/deprecations?openUsages=WzIsM10

[big-guy]

I fixed the above two cases