feat: OAR031 independent per-level examples coverage with configurable validation

[rafael-goterris]

Feature Request

Describe the Feature Request

OAR031 (ExamplesCheck) currently decides whether a response, request body or parameter
"has an example" by walking the schema recursively (isSchemaCovered): a single example
found anywhere — including on a nested property — satisfies the whole check. As a result:

• A response/request body that lacks a representative (media-type / root-schema) example is
  not flagged as long as some property carries an example.
• There is no way to enable/disable the check per level.
• It diverges from the Spectral ruleset, which was updated to validate levels
  independently — so the two engines can report different findings for the same OpenAPI.

Describe Preferred Solution

Validate examples as four independent levels, each with its own message and configurable
via rule parameters (all enabled by default):

Level	Rule parameter	Requirement
Response	validateResponse	A media-type or root-schema example
Request body	validateRequestBody	A media-type or root-schema example
Parameter	validateParameter	An example on the parameter or its schema root
Property	validateProperty	An example on each leaf property

• The response/request-body/parameter levels require an example at the media-type or schema
  root (non-recursive); examples buried in individual properties no longer satisfy them.
• Levels are checked independently; 204 responses are excluded.
• Behaviour and findings must be identical to the Spectral ruleset (same engine parity).

Describe Alternatives

• Keep the recursive isSchemaCovered (status quo): rejected — it cannot distinguish a
  representative example from a buried property example, and it diverges from Spectral.
• Hierarchical model (a body example exempts property checks): rejected in favour of fully
  independent levels, which match Spectral and are clearer to configure.

Related Code

• Check: OAR031ExamplesCheck (apiaddicts.sonar.openapi.checks.examples)
• Rule parameters via @RuleProperty (camelCase): validateResponse, validateRequestBody,
  validateParameter, validateProperty
• Messages: errors.properties / errors_es.properties (OAR031.error-*)
• Parity check harness: DiagnosticGestionTest

Additional Context

• Counterpart of the Spectral ruleset change (apiaddicts-style-guide-spectral issue #155).
• Parity verified against the updated Spectral ruleset on the same OpenAPI document:
  identical findings on both engines — 446 property + 12 request body + 21 response = 479.
• Param keys are camelCase to match Spectral functionOptions and the single config key
  used across the platform (front → back → both engines), avoiding key mapping.
• New default is stricter than the current behaviour (responses/request bodies now require
  a representative example regardless of property examples), so existing specs may surface new
  findings — suggest a minor (or major) version bump on release.
• Tests cover OpenAPI 2 / 3 / 3.1 / 3.2 and every toggle; full suite green.

If the feature request is approved, would you be willing to submit a PR?
Yes — implementation, tests and docs are already prepared.