increase lifecycle bindings priority against pom ones

[hboutemy]

Summary

Fix goal bindings in pom.xml being executed before lifecycle bindings for
the clean and site lifecycles (regression vs Maven 3, fixes #12331).

Root cause

Lifecycles.plugin() creates executions for built-in clean and site
lifecycle bindings (e.g. default-clean) without setting a priority, so they
defaulted to 0 — the same as user-defined executions from pom.xml.

DefaultLifecycleMappingDelegate sorts executions within a phase by priority.
When both a lifecycle binding and a pom.xml execution share priority 0,
ordering falls back to plugin iteration order. Because LifecycleBindingsMerger
inserts pom.xml plugins before lifecycle-only plugins, pom.xml executions ended
up running first.

For the default lifecycle this was not a problem: packaging bindings (e.g. for
jar) are built by DefaultPackagingRegistry with priority(i - mojos.size())
— always negative — so they already sort before user executions.

Fix

Add .priority(-1) to the PluginExecution built in Lifecycles.plugin(),
making clean and site lifecycle bindings consistent with how default
lifecycle packaging bindings work.

Test plan

• LifecycleExecutorTest, DefaultLifecyclesTest, BuildPlanCreatorTest
  all pass (561 tests, 0 failures in maven-core)
• Manual reproduction from goal bindings in pom.xml executed BEFORE lifecycle ones with Maven 4 #12331: mvn clean with an antrun execution
  bound to the clean phase now runs default-clean (maven-clean-plugin)
  before the pom.xml antrun execution, matching Maven 3 behavior