Replace direct usage of compileOnly configuration for resolution

[breskeby]

Removes direct access to compileOnly which is deprecated for direct resolution. (see deprecation warning in build scan https://gradle-enterprise.elastic.co/s/v7ggsljig4i44/deprecations#deprecation-1 )

Fixes #56998

• registers a resolvable configuration that extends compileOnly for resolution purposes
• also breaks up the integration tests in the build-tools project in separate sourceSet as discussed with @mark-vieira.
• leverages the core test fixtures plugin to share test fixtures among multiple sourceSets
• some minor detangling on task dependencies in ThirdPartyAudit task do get better testability
• tweak ThirdPartyAuditTaskIT to assert for non expected gradle deprecations

[mark-vieira]

LGTM, the only thing is I think we can remove the usage of compileOnly in most, if not all cases, no? In reality what we want is either compileClasspath or runtimeClasspath. I think we are mistakenly referencing compileOnly in many cases. In the case where we all, dependencies, that is, everything we compile against and run against, that's were we are concatenating compileOnly with runtime, but could we just as well do compileClasspath + runtimeClasspath to get the same superset? We'd remove the duplicate jars of course to avoid jarHell but isn't that the same result? Then we can ditch any use of compileOnly altogether?

[breskeby]

@mark-vieira I didn't want to change to much but we should definitely revisit the usage of compile only. I left it there for now as in the cases here its mainly used to solve use cases like this here explained by @rjernst #56998 (comment)