Fix inconsistent snippet selection for OpenAPI docs

[aleximenes]

As it is possible to provide multiple snippets for a single endpoint,
the API documentation logic has to decide which snippets should define
the identity of the merged operation or item.

Previously, OpenAPI 3 derived a merged operationId from the common
prefix of snippet operationIds, falling back to sorted concatenation
when no common prefix existed. OpenAPI 2 did not merge at all and
simply took the operationId of whichever snippet happened to be first,
which was arbitrary and order-dependent. Postman had its own partial
handling of the same problem.

This change makes the behavior consistent across OpenAPI 2, OpenAPI 3,
and Postman. A shared selection strategy is now used to pick primary
candidates for merged identity. It prefers 2xx over non-2xx, applies
status priority in the order 200, 201, 202, 204, then other 2xx, then
prefers non-blank summary and description, and finally uses lexical
operationId as a tie-breaker.

A shared merged operationId rule is now used as well. The merged ID is
derived from the common prefix across selected operationIds. When no
common prefix exists, the rule now falls back to the top-priority
candidate's own operationId instead of concatenating all sorted
operationIds. Concatenation produced unreadable, codegen-hostile
identifiers (e.g. "products-createvariation-products-create") for the
common and legitimate case of multiple snippets documenting the same
path and method, which broke generated client method names downstream.
This fallback change applies to OpenAPI 2, OpenAPI 3, and Postman alike,
since all three share the same merge rule.

OpenAPI 2 now also derives operationId from merged candidates instead of
taking it directly from one selected snippet. Postman top-level item id
now follows the same merged operationId rule, while description and
request defaults still come from the selected primary candidate.

Tests were added and extended to cover success versus error-only merge
selection, 200 preferred over 201, and no-common-prefix fallback
behavior across all three generators. The README and CHANGELOG now
document merged snippet identity selection and operationId derivation
behavior consistently.

This keeps the success-first intent, removes generator-specific drift,
and avoids both arbitrary naming caused by snippet input order and
unreadable concatenated names when no common prefix exists.

Fixes #255

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud