Populate java compiler args

[Arthurm1]

Populate the missing javac options - before it was the only the additional used specified options that appeared.

[nickzhums]

@Arthurm1 Thank you so much for the contribution! Since there is a lot of PRs pending, it's gonna take some time for review, please allow us some time :) again, thanks so much!

[nickzhums]

@Arthurm1 meanwhile, feel free us to let us know if you have any feedback using the product, anything is useful to us, thanks

[jdneo]

Except for the Checkstyle violations, this change looks good to me.

With this PR merged, looks like we can get rid of

https://github.com/microsoft/build-server-for-gradle/blob/develop/model/src/main/java/com/microsoft/java/bs/gradle/model/GradleSourceSet.java#L92-L100

and recover the source and target compatibility from the compiler args. I'll do that later.

[Arthurm1]

Fixed checkstyle issues

[jdneo]

Since it's using internal apis, there might be chances to meet NoSuchClass/NoSuchMethod error.

Do we have public utils that can be used? If not, considering adding a try-catch block and use the original implementation as a fallback.

[Arthurm1]

I've wrapped the code in try-catch as there are no public classes that create the full args list. The other option is to duplicate the JavaCompilerArgumentsBuilder class but there's a lot of code in there and it's subject to change so it would have to be maintained.

I've added more tests as I wasn't handling the --release flag properly.

I've added code to cope with Groovy's use of GStringImpl when Strings are built using String interpolation e.g. "${variable}". This causes IllegalArgumentException when returning data through the tooling API so these have to be manually converted to Strings. Yuck

[Arthurm1]

Hopefully I've addressed all your points.

The source and target compatibility are now both set from the compiler args. Before, if a build had set the source/target directly in the args, then the compatibility settings would be wrong.
If nothing is set in the project's build file then Gradle automatically adds the current JVM version to the compiler args. So these should always be set in DefaultGradleSourceSet and hence in JvmBuildTargetEx.

I've added to the tests to check for both these issues.

[jdneo]

Looks good to me.

I should probably add a test for toolchains as well, in case they set the source/target/release in a different manner

Would you like to add a toolchain test in this PR? I'm both ok if merging the PR as it is.

[Arthurm1]

@jdneo I've added a toolchain test. No other changes. Hopefully good to merge now

[jdneo]

Thank you @Arthurm1!