Add MultiDataSourcePrepAndExpectedTestCase to prep and verify multiple data sources in one test

[jeffjensen]

Problem

DefaultPrepAndExpectedTestCase packages a full DbUnit lifecycle — load prep data,
run test steps, verify tables against expected data, clean up — against one
IDatabaseConnection. Every field, every PrepAndExpectedTestCase method, and the
whole lifecycle are 1:1 with a single IDatabaseTester.

A test that exercises code spanning two or more databases (an "orders" DB and an
"inventory" DB; an application DB plus a shared reference DB) has no way to prep and
verify tables in each database around one run of the code under test. It must
hand-drive a second IDatabaseTester and reimplement the setup / verify / cleanup /
connection bookkeeping itself.

There is no multi-connection abstraction anywhere in DbUnit to build on:
DatabaseOperation.execute is (one connection, one dataset), CompositeDataSet is
connection-agnostic and cannot route tables to different connections, and
TesterResolver (the annotation path) deliberately rejects more than one tester.

Proposal

A new focused type, MultiDataSourcePrepAndExpectedTestCase, that composes one
PrepAndExpectedTestCase delegate per data source (each normally a
DefaultPrepAndExpectedTestCase bound to its own IDatabaseTester) and orchestrates
the shared lifecycle: prep every data source, run the test steps once, verify
every data source, clean up every data source.

DefaultPrepAndExpectedTestCase and the PrepAndExpectedTestCase interface are
untouched — the single-source path is reused whole, per data source. This mirrors
DbUnit's existing CompositeDataSet / CompositeOperation / CompositeTable
precedent and the project's composition-over-inheritance direction.

It does not implement PrepAndExpectedTestCase: the interface's singular
accessors (getPrepDataset(), getDatabaseTester(), getReusableConnection()) and
singular configureTest / preTest / runTest have no honest answer for N data
sources. It is a peer type with a parallel, map-keyed API plus per-data-source
accessors.

// wiring - fixed per test class
MultiDataSourcePrepAndExpectedTestCase testCase =
        MultiDataSourcePrepAndExpectedTestCase.forTesters(dataFileLoader, Map.of(
                "orders", ordersTester,
                "inventory", inventoryTester));

// data - varies per test method / per @ParameterizedTest row
testCase.runTest(Map.of(
        "orders", new PrepAndExpectedTestData(ORDERS_VERIFY, ORDERS_PREP, ORDERS_EXPECTED),
        "inventory", new PrepAndExpectedTestData(INV_VERIFY, INV_PREP, INV_EXPECTED)),
        () -> { /* exercise code that writes to both databases */ return null; });

Orchestration: setup and verify iterate in declared order, teardown in reverse; verify
collects failures across all data sources rather than stopping at the first; a partial
setup failure rolls back the data sources already set up. Each delegate manages its
own connection exactly as today.

Scope

Programmatic API only, matching where DefaultPrepAndExpectedTestCase is used today.
Annotation / DbUnitExtension integration is tracked separately in #969.

Out of scope: a single dataset file whose tables route to different data sources;
cross-data-source referential-integrity ordering beyond the declared-order guarantee;
QueryDataSet / partial multi-source datasets.

Dependencies

Depends on #938 (PrepAndExpectedTestData) — the per-data-source data unit the map
API takes. Three parallel Map<String, ...> arguments would be unusable. Builds on
the feat/annotation-driven-setup branch (#946): the widened PrepAndExpectedTestCase
interface and org.dbunit.database.connection.*.

Relationship to #938 and #753

PrepAndExpectedTestData (#938) bundles the prep / expected / verify triple that
varies per invocation; this issue keys a map of those by data-source name. #753's
annotations serve configuration fixed per test method; both this and #938 serve
configuration that varies per invocation.