TestKit should make it possible (and easy) to specify the JDK and other dependencies, similarly to how one can use withGradleVersion()

[autonomousapps]

This is a two-parter and arguably should be two issues, but they seem related in kind.
JDK
With Gradle 6.3, it is now possible to build projects with Java 14, yet if one sets that as their default JDK, any TestKit tests that run against other versions of Gradle (i.e., any and all of them), the tests will fail.

On the Gradle Community Slack, @big-guy suggested there was a workaround that involved injecting a gradle.properties file into the test with org.gradle.java.home set, but I have not been able to get it to work (details in thread). I'd be happy to have that workaround clearly documented, but nevertheless think that TestKit and GradleRunner should provide an idiomatic, "non-workaround" approach to this.

Other Dependencies
In similar fashion, I'd like to be able to inject different versions of runtime dependencies into the tests. In my plugin, I test compatibility with versions of AGP from 3.5.3 to the latest 4.1 alpha. Actually getting these different versions onto the test classpath is non-trivial, and requires workarounds that can be seen in my build script; even with that, I need to use bash to run the tests multiple times, with different versions of AGP each time. I'd like an idiomatic way to do this that doesn't require build script gymnastics and a bash wrapper.

Expected Behavior

1. There should be a method GradleRunner#withJdk()
2. There should be a method GradleRunner#withClasspath()

Current Behavior

1. There is no straightforward way to use a different JDK with TestKit. The workaround suggested by Sterling did not work in my case (happy to learn I did something wrong).
2. Using different classpaths requires build script gymnastics and a bash wrapper. Each test run produces a separate test report and build scan, when logically it should be one report and one scan.

Context

See the discussion above.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[3flex]

Another use case for injecting runtime dependencies: running integration tests for a Gradle plugin with runtime dependencies from the project.

To build on the example from the issue above:
GradleRunner.create().withClasspath(project(":cli"))