feat: support multiple REST client configurations via `rest-clients` list in test suite YAML

[snytkine]

Summary

Replace the single rest_client configuration block in the test suite YAML with either:

• A rest-client block (singular) — shorthand for a single default REST client, or
• A rest-clients list (plural) — supports multiple named REST client configurations.

Each entry in rest-clients gets a unique id. Requests in a test case can then select which REST client to use via a rest-client property on the request.

---

Motivation

Currently only one REST client can be configured per suite. Some test suites need to call multiple backend services or environments that differ in base URL, authentication, timeout, or TLS settings. The rest-clients list lets a single suite cover all of them without duplication. The rest-client singular form is retained as a convenient shorthand for simple single-service suites.

---

YAML Schema Change

The old rest_client key (underscore) is removed. Two new keys are supported — exactly one must be present.

Option A — single REST client (shorthand)

rest-client:
  base-url: https://api.example.com
  timeout: 30
  # ... all currently supported rest client properties

Treated identically to a rest-clients list with one entry having id: default. No id field is allowed or needed here.

Option B — multiple REST clients

rest-clients:
  - id: default
    base-url: https://api.example.com
    timeout: 30

  - id: payments
    base-url: https://payments.example.com
    timeout: 10

Each entry supports all properties currently supported under the old rest_client, plus the required id field.

---

Semantics

The default REST client

• Under rest-client (singular): the single block is always the default.
• Under rest-clients (list): the entry with id: default is used by every request that does not explicitly specify a rest-client property.
• If rest-clients contains exactly one entry and it has no id, it is treated as the default implicitly.

Per-request REST client selection

A request in a test case may specify:

tests:
  - name: Pay invoice
    request:
      rest-client: payments   # references an id from rest-clients list
      method: POST
      path: /invoices/pay

If rest-client is omitted on the request, the default REST client is used.
The rest-client property on a request is only meaningful when rest-clients (plural) is used in the suite config; it is ignored (or a warning is logged) when rest-client (singular) is used.

---

Validation Rules (early, fail-fast)

These validations must run at the same stage as the existing unique-test-name validation.

#	Rule	Error
1	Exactly one of rest-client or rest-clients must be present. Neither is an error; both is an error.	Test suite must define exactly one of 'rest-client' or 'rest-clients', but found neither / …found both
2	id values across all entries in rest-clients must be unique.	Duplicate rest-client id: '<id>'
3	If rest-clients contains more than one entry, every entry must have an id.	rest-client at index <n> is missing required 'id' (required when multiple rest-clients are configured)
4	If a request specifies rest-client: <id>, that <id> must exist in the rest-clients list.	Test '<name>' references unknown rest-client id: '<id>'

Code style guidance

• Prefer static methods for each validation rule (thread-safety, easy to unit-test in isolation).
• Each rule should live in its own method; compose them into a single validateRestClients(TestSuite suite) entry point.
• Follow the same pattern as existing suite validation logic.

---

Acceptance Criteria

• Both rest-client (singular) and rest-clients (plural) are parsed; old rest_client (underscore) key is removed.
• rest-client singular is treated as a default REST client with no id required.
• rest-clients list maps to List<RestClientConfig> (or equivalent record) where each entry includes all existing fields plus id.
• The id field on a rest-clients entry is optional only when exactly one entry is present; otherwise it is required.
• Requests can specify rest-client: <id>; the engine picks the matching RestClientConfig.
• Requests without rest-client use the default REST client.
• All four validation rules above are enforced early (same phase as test-name uniqueness check), with clear error messages.
• Each validation rule is implemented as its own static method.
• Unit tests cover: rest-client singular form, single-entry rest-clients (no id), single-entry rest-clients (with id), multiple clients (all with ids), neither present (error), both present (error), duplicate id (error), missing id when multiple exist (error), unknown rest-client reference on request (error).
• docs/test-suite-configuration.md and README.md updated to reflect the new schema.
• Spotless passes, all existing tests remain green.