Favor running compile tasks before pre-commit

[alpar-t]

With this change we won't need to call ./gradlew compileJava before calling precommit.
This is not 100% what CI achieved. To do that we would need to set up this relationship between all the tasks between all the projects so that compile is done for all projects first, not just this one.
I think this will be sufficient and we can leave the rest up to Gradle as it will already order projects based on dependencies.

[elasticmachine]

Pinging @elastic/es-core-infra

[rjernst]

This will only ensure precommit tasks within each project are run after their respective compilation tasks. But when we run compileJava first in CI, it is to ensure all projects' compilation are run first. This change is fine as is, but I want to make sure there is no confusion about why explicit tasks in CI still have a purpose.

[jasontedor]

The point of compileJava compileTestJava precommit indeed is exactly that we run compilation across the board before doing anything else so that we can fail fast on a common source of errors.

[alpar-t]

I realize this is not exactly what CI does, but wanted to open it up for discussion as it seems to me that it could be acceptable. Compilation will happen before precommit on a per project level and Gradle will prioritize projects order based on how the project dependencies are set up.
This means that if say :server:precommit fails it is possible that it will potentially mask a compilation failure on a project further down the chain indeed. If Gradle does get to it in parallel, it will show both failures. I didn't wire this from the root project across all the project and tasks because I wanted to make sure that we really need to add that extra complexity. If we do I will do that, because I do think we should have this in Gradle.

The goal is to only have ./gradlew precommit --parallel in CI following this change.