feat(ls): OpenAPI 3.x.x mutually exclusive lint rule for Media Type

[tim-lai]

Description

Add lint rule of "mutually exclusive" for example and examples fields. Applies to both OAS3.0.x and OAS3.1.x

Motivation and Context

Ref: #2061
Ref: #2033
Ref: #2062 (no update required)

How Has This Been Tested?

local.

sample fixture (should yield marker error on examples):

openapi: 3.1.0
info:
  title: deref
  version: 1.0.0
paths:
  /a:
    get:
      responses:
        '200':
          description: a pet to be returned
          content: 
            application/json:
              schema:
                # $ref: '#/components/schemas/Pet'
                type: object
              example:
                confirmation-success:
                  summary: singe confirmation success
              examples: 
                confirmation-success:
                  summary: short confirmation success
                  description: longer confirmation success
                  value:
                    # Example value starts here
                    id: 17
                    name: T-shirt
                    description: 100% cotton shirt
                    categories: [clothes]

Screenshots (if appropriate):

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.