feat: add Doctrine DBAL and in-memory storage adapters, selected via new storage config option

[paullla]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Issues	-
License	MIT

Problem

Since 2.0 the core talks to three storage-agnostic interfaces, but Elasticsearch is still the only implementation the bundle ships. Requiring an Elasticsearch cluster just for activity logs is the biggest adoption blocker: most Symfony apps already run Postgres or MySQL and already depend on Doctrine. Custom backends are possible via alias overrides, but that means every team writes and maintains its own adapter. Test suites (ours and users') also had no way to run the full logging flow without a real backend.

Changes

• New Doctrine DBAL storage adapter in Locastic\Loggastic\Bridge\Doctrine\Storage (DoctrineActivityLogStorage, DoctrineCurrentDataTrackerStorage, DoctrineStorageInitializer). All loggable classes share two tables (loggastic_activity_log, loggastic_current_data_tracker) discriminated by an indexed object_class column, with JSON columns for changes/tracker data. The schema is created through the DBAL schema API and all values go through DBAL type conversion, so the adapter works on PostgreSQL, MySQL, SQLite and anything else DBAL supports. Timestamps are normalized to UTC on write. Table names are constructor arguments with defaults, overridable via service configuration
• New in-memory storage adapter in Locastic\Loggastic\Storage\InMemory mirroring the same sorting, pagination and class-discrimination semantics, so test suites can run the full logging flow with zero external services
• New storage config option (elasticsearch | doctrine | in_memory, default elasticsearch, so existing apps are unaffected). Picking a backend is now one line of config instead of three service aliases. When a non-Elasticsearch backend is selected, no Elasticsearch service is registered at all: the bundle boots without the ES client or any elastic_* configuration. Alias overrides keep working for fully custom backends
• doctrine/dbal (^3.8 || ^4.0) added as an explicit dependency (previously only transitive via ORM); composer description updated to reflect pluggable storage
• README: new "Choose your storage" section up top, storage key documented in the configuration reference; CHANGELOG updated

Verification

• Full PHPUnit suite passes (47 tests, 144 assertions): 10 new integration tests exercise the Doctrine adapter on an in-memory SQLite connection (round-trips including nullable fields, UTC normalization, sorting, pagination, multi-class discrimination, per-class recreate, tracker update/bulk-save); 8 new unit tests cover the in-memory adapters; a new functional test boots the fixture app with storage: in_memory and runs the full create/no-op-update/edit-diff/delete flow through ActivityLogger; a wiring test boots with storage: doctrine and asserts the interfaces resolve to the Doctrine bridge with no Elasticsearch services registered
• Both DBAL majors exercised: the bundle test suite runs on DBAL 4.4, and the demo application validation below ran on DBAL 3.10
• Demo application (Symfony 6.4 + Postgres 15) switched from its app-level adapter to storage: doctrine: full create/child-edit-diff/delete flow verified, and all 13 backend-parity edge-case checks pass (no-op updates, forced logs, orphan-removal diffs, cross-class isolation, pagination, tracker recreate/populate/rebuild)
• PHPStan reports no errors (no new baseline entries); PHP-CS-Fixer reports 0 fixable files; composer validate --strict passes