Strip executable() conditions from consumer POMs

[gnodet]

Context

PR #12332 added the executable() function for conditional profile activation (MNG-8768). During review, it was identified that executable() conditions survive into published consumer POMs via DefaultConsumerPomBuilder, which means:

• A consumer pulling the POM from a repository will silently evaluate the executable() condition against their own PATH
• Two developers building the same project can get different effective models depending on installed tools
• The model validator warning added in [MNG-8768] Add executable() function for conditional profile activation based on PATH #12332 only fires for the POM author, not downstream consumers

Proposal

Strip executable() conditions from consumer POMs during DefaultConsumerPomBuilder processing, similar to how <build> sections are stripped from profiles. This ensures the function remains useful for local build decisions without polluting published artifacts.

References

• PR [MNG-8768] Add executable() function for conditional profile activation based on PATH #12332: [MNG-8768] Add executable() function for conditional profile activation based on PATH #12332
• Original issue: MNG-8768 / [MNG-8768] Add a function for conditional profile activation evaluating to true if a certain executable can be found in the system path #10115
• Review discussion: [MNG-8768] Add executable() function for conditional profile activation based on PATH #12332 (review)
• Contributor agreed to tackle this as a follow-up: [MNG-8768] Add executable() function for conditional profile activation based on PATH #12332 (comment)