Defer DBAL removal pending Builder dependency transition

[samuelpatro]

Removing Rain's DBAL requirement can break existing Builder installations: current Builder registers a Doctrine type and uses Doctrine schema classes, but does not declare DBAL directly.

This revision defers removal and retains doctrine/dbal: ^2.13.3|^3.1.4. The develop Composer conflict is resolved while preserving PHP ^8.2 and larajax ^3.0. The net change against develop is a concrete transition proposal in docs/dbal-dependency-transition.md, including the companion Builder dependency patch and release gates.

Before a future removal, Builder needs a published direct-dependency release, verified Composer/marketplace dependency delivery, and a protected upgrade path for older installations. No compatible release number or conflict range is assumed. Other consumers also require auditing. Companion publication and full upgrade validation remain maintainer work; this PR does not remove the runtime dependency.

Validation: Composer manifest validation passes with the existing missing-license warning. Isolated PHP 8.4 smoke tests with DBAL 2.13.9 and 3.10.6 pass Builder's actual timestamp type registration, MySQL/SQLite declarations, and basic Doctrine schema-column construction. The library suite passes 255 tests / 1499 assertions with one pre-existing risky test. These are not full Builder compatibility tests and do not validate marketplace installation, all schema tools, or every supported dependency version.

The earlier claim that no plugin references DBAL was incorrect; library/CMS tests alone cannot establish Builder compatibility.

[daftspunk]

It's used by Builder I think

[samuelpatro]

Recheck of head 70b57959 against current Builder source found a compatibility blocker.

[P1] Preserve Builder's DBAL dependency before removing Rain's requirement. Builder Plugin.php calls Doctrine\DBAL\Types\Type::hasType() during plugin registration, and its database tools also use DBAL. Builder composer.json does not declare DBAL; it relies on Rain supplying it. The maintainer's concern above is confirmed.

On an installation with Builder and no other DBAL dependency, updating dependencies after this removal can remove DBAL and make registration fail with a missing Doctrine class. Library/CMS suites without Builder do not cover this. Retain the requirement until Builder declares a compatible direct dependency and the release transition is accounted for, or coordinate that migration before merging. Narrow the description's claim that no plugin references DBAL.

The branch also conflicts with current develop in composer.json; retain develop's PHP/larajax requirements when updating.

[samuelpatro]

Closing this. Builder uses DBAL without requiring it, so dropping it from Rain has to wait until Builder declares it directly.