Fix configuration cache compatibility issues in gradle plugins

[breskeby]

This fixes references to project that makes the plugin incompatible with Gradle
configuration cache

Related to #57918

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)

[breskeby]

@pugnascotia I'll ping you again when done here. Sorry should have been a draft. I want to fix more related issues before merging

[breskeby]

@pugnascotia
I think this is ready now. There's more to fix around task listeners and LoggedExec, but that requires more rework that I don't want to mix with other stuff and keep it separated

[pugnascotia]

Is the xpackProject utility redundant now, or is it going to become redundant? I'm curious about why we're moving away from it?

[breskeby]

@pugnascotia the problem with xpackProject was that:

1. using xpackProject in certain situations can break configure configuration cache compatibility as it uses a mutual project object under the hood that is discouraged to use in some use cases (e.g. at execution time)

2. It always breaks compatibility with --configure-on-demand

3. using xpackProject uses the project of the :x-pack project. referencing other project objects from other subproject should avoided where possible to decouple (sub project configurations). There's a good explanation of why we want to decouple our project configurations as much as possible here: https://docs.gradle.org/current/userguide/multi_project_configuration_and_execution.html#sec:decoupled_projects

4. it adds little value over default out of the box gradle api (just use project(':x-pack:someProject') instead of xpackProject('someProject') Also in some occasions its even shorter. e.g. when this is used as xpackProject('someProject').path instead of just passing :x-pack:someProject

I'll try to put a bit more context in the PR description in the future to make the motivation behind these kind of changes more clear upfront