IBX-11939: Moved the baseline fixture import into its own bootstrapper hook

[Steveb-p]

🎫 Issue	IBX-11939

Related PRs:

• IBX-11939: [Doctrine Migrations] Added Doctrine Migrations-based schema and data install path (inlined SQL) core#785
• https://github.com/ibexa/measurement/pull/133

Description:

The baseline repository content in test_data.yaml has a second source: on the Doctrine
Migrations install path, ibexa/core's ImportDataMigration inserts the same rows from its
import-data SQL. Both write the same primary keys, so importing the fixture on top of the
migration collides — the bootstrapper needs a way to leave it out.

My first attempt did that with a marker (BaseFixture) plus a skip_base_fixture option on
FixtureHook, and it doesn't hold up. The provider chain is a replacement mechanism — one
provider wins and decides what a package contributes — while the baseline is an "always",
independent of that choice. Putting the two in one list makes the baseline something a package
can lose by accident, in two ways. corporate-account composes it into its own output by
unwrapping with Fixture::load() and re-merging into an anonymous Fixture, so the marker is
gone before the hook ever sees it. And setting ibexa.test.fixture_files outranks the
kernel-method provider (100 vs 0), so it drops the baseline outright — nothing uses that
parameter yet, but it's the mechanism we want people to move to.

So the baseline is now its own hook. BaseFixtureHook reads DefaultFixtureProvider directly
and imports it at priority 950 — after the schema is in place, before the package fixtures
layered on top. load_base_fixture defaults to true; the Doctrine Migrations bootstrap sets
it to false. FixtureHook and the chain now mean package fixtures only, and
IbexaTestKernel::getFixtures() stops yielding the baseline — it's deprecated and BC-only, and
the hook covers every kernel regardless of what that method does.

Nothing breaks in the interim for packages that still yield from $this->defaultProvider: the
baseline just gets imported twice, which truncates and reinserts the same rows. Wasteful, not
wrong. Those yield from lines can come out per package afterwards.

One case does need a change though — corporate-account merges its fixtures into a single
synthetic one precisely because FixtureImporter truncates before inserting, and
test_company.yaml writes into six tables the baseline also populates
(ezcontentobject, _attribute, _link, _name, _tree, _version). Once the baseline is a
separate import() call, that has to become an AppendOnlyFixture — which is the matching piece
in ibexa/core#785. I checked the other packages' fixture tables; cart, order-management and
discounts are fully disjoint from the baseline, so they're unaffected.

One more thing fell out of this, unrelated to the hook split itself. test_data.yaml had language
ID 2 as eng-US and ID 8 as eng-GB, while ibexa/core's cleandata.sql - and the
ImportDataMigration generated from it - gives ID 2 eng-GB, and doesn't define ID 8 at all.
Nothing ever loaded both datasets into the same database, so the two mappings never had to agree
with each other. Once the baseline comes from the install data and the package fixtures are layered
on top of it, they do.

So I swapped them: ID 2 is eng-GB as in a real install, and eng-US moves to ID 8. It's a large
diff (286 lines each way) because every serialized locale string in the file has to follow the ID
it's attached to, but it's a pure string swap - the IDs and the language masks are untouched, so
content stays in the same rows with the same masks.

[alongosz]

ATM 4.6.33, but given we don't release test-core, not sure if that makes sense either.

[Steveb-p]

Changed to 4.6.33 across the whole PR.