fix(err): filter false-positive ExampleElement mutually exclusive resolver errors

[maruthang]

Description

Added an ExampleMutuallyExclusive error transformer that filters out false-positive resolver errors where apidom-reference incorrectly reports "ExampleElement value and externalValue fields are mutually exclusive" when only externalValue is present. The transformer is registered in the error transformer hook alongside the existing not-of-type and parameter-oneof transformers.

Motivation and Context

Fixes #10418

When a spec uses $ref at the path level and the referenced file contains examples with externalValue, the upstream apidom-reference library throws a false-positive mutual exclusivity error. This causes Swagger UI to display a spurious error message to users even though their spec is valid. This fix suppresses those false-positive errors at the error transformer layer, following the same pattern already used for other known false-positive errors.

How Has This Been Tested?

• Added 4 regression unit tests in test/unit/core/plugins/err/transformers/example-mutually-exclusive.js:
  • Filters out false-positive ExampleElement mutually exclusive resolver errors
  • Preserves non-resolver errors with the same message text
  • Preserves other resolver errors (e.g., network errors)
  • Correctly handles mixed errors (filters only the false-positive, keeps the rest)
• ESLint passes on all changed files

Screenshots (if appropriate):

N/A - no UI changes.

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.