feat(multi-version): foundation for DuckDB v1.4.4 LTS + v1.5.x support (selector script + Makefile target + doc)

[estebanzimanyi]

Summary

Step 1 of the multi-DuckDB-version effort — same pattern as MobilityDB-on-Postgres compiling against PG 13-18 from one source tree, applied to DuckDB extension ABIs.

DuckDB extension ABI is version-specific: a binary built against v1.4.4 cannot load into v1.5.2 and vice versa. MobilityDuck therefore needs to produce a separate binary per (duckdb_version, platform). Selection is driven by the SHAs that the three submodules — duckdb, duckdb-spatial, extension-ci-tools — point at when the build runs.

This PR adds the foundation that the rest of the multi-version story builds on. No behaviour change: existing builds work identically; the v1.5.x track is one make set-duckdb-version DUCKDB_VERSION=v1.5.2 away from being buildable; the CI matrix PR (step 2) turns it on across the build matrix in one place.

Files

File	Role
scripts/select-duckdb-version.sh	Per-version manifest mapping a DuckDB version to matching duckdb-spatial and extension-ci-tools refs. Switches the three submodules in lockstep when invoked.
Makefile	New variable DUCKDB_VERSION (default v1.4.4, the ecosystem alignment target) and a make set-duckdb-version target that delegates to the script.
doc/multi-duckdb-version.md	Full design: per-version manifest, build-flow diagram, how to add a new supported version, relationship to the (future) CI matrix, adopter install path.
README.md	Single-sentence pointer telling adopters which versions are supported and where the multi-version doc lives.

Supported versions (manifest)

DuckDB	Track	duckdb-spatial branch	extension-ci-tools branch
v1.4.4	LTS (default)	v1.4-andium	v1.4.4
v1.5.2	Latest 1.5.x (opt-in)	v1.5-variegata	v1.5-variegata

Usage

# Switch the working tree to v1.5.2 (downloads + checks out the matching submodule SHAs)
make set-duckdb-version DUCKDB_VERSION=v1.5.2

# Then the normal build flow targets that version
make release

# Return to the committed default (v1.4.4)
git submodule update --recursive

What this PR explicitly does NOT change

• The committed submodule SHAs (still v1.4.4 — the default build is identical).
• MainDistributionPipeline.yml (CI still builds for one version; the matrix expansion is the next PR, stacked on this one).
• Any C++ source (preprocessor conditionals for API divergences land alongside the CI matrix once a second version's build surfaces them).

Next steps (separate PRs, stacked on this one)

Step	Scope
2	CI matrix expansion: MainDistributionPipeline.yml duckdb_version: [v1.4.4, v1.5.2] matrix dimension; each row calls make set-duckdb-version before make release.
3	Source preprocessor conditionals for any DuckDB API divergence the matrix surfaces (ExtensionUtil → ExtensionLoader, the bundled spatial-extension surface, etc.).
4	Per-version expected-output variants in test/sql/*.test for any case where DuckDB's own behaviour changed between versions.
5	README + community-extension config: enumerate the supported versions and the install path per version.
6	MVB benchmark cross-version reporting.