Support special IDREF validation via ExtensionsErrorReporter.isPresent

[merks]

Support special IDREF validation via ExtensionsErrorReporter.isPresent

• The quicklinks.exsd defines two attributes that are specified as IDREFs to command IDs but they actually permit a command spec and even wildcards.
• This leads to warnings when those aspects are used and those warnings are impossible for the user to fix.
• If we disable the basedOn type for those, the extension attributes no longer support Browse... to find a command, which makes authoring very inconvenient.
• Ideally PDE is made aware of these special attribute so support specialized validation.

In EPP there are a bunch of quicklinks definitions, e.g.,

https://github.com/eclipse-packaging/packages/blob/d0d154a80c075e857dcf531396546686ec844dba/packages/org.eclipse.epp.package.committers/plugin.xml#L390-L439

So we end up with lots of warnings that we can't eliminate:

[merks]

For

https://github.com/eclipse-packaging/packages/blob/d0d154a80c075e857dcf531396546686ec844dba/packages/org.eclipse.epp.package.committers/plugin.xml#L390-L439

without this fix we have these warnings:

With the fix we have only these warnings:

These are legitimate because those are not in the target platform in the self-hosted debug launch.

[github-actions]

Test Results

   765 files  ±0     765 suites  ±0   53m 45s ⏱️ -7s
 3 611 tests ±0   3 535 ✅ ±0   76 💤 ±0  0 ❌ ±0 
10 833 runs  ±0  10 602 ✅ ±0  231 💤 ±0  0 ❌ ±0 

Results for commit a492478. ± Comparison against base commit 77439fd.

♻️ This comment has been updated with latest results.

[HannesWell]

From what you have described, it sounds like there is no good solution for the problem, besides reworking the specification and validation of extension-points in general.
Of course the latter would be better then to have special handling of certain extension-point values in PDE, but I would be ok with this.

OTOH, a relatively simple generic solution could be introducing the possibility to declare a custom validator (for attributes?) when defining a new extension-point? Then platform.ui could inject the custom validation for the affected points.

[merks]

FYI @jonahgraham

Woo hoo, with this change, the EPP environment can be provisioned without any warnings: