Tracking issue: Split ecosystem integrations out of the core repository

[Xuanwo]

Feature Description

OpenDAL currently keeps several ecosystem integrations under integrations/, including Rust adapters such as object_store_opendal, parquet_opendal, dav-server-opendalfs, unftp-sbe-opendal, and the Spring integration modules.

These packages are ecosystem adapters rather than part of OpenDAL's core storage abstraction. We should split them out of the core repository so each integration can follow its own ecosystem, dependency, CI, and release cadence while keeping OpenDAL core focused on the abstraction, services, layers, and testkit.

Problem and Solution

Keeping integrations in the core repository creates several forms of coupling:

• core CI and release workflows need to know about integration-specific build systems and package versions;
• integration versions can be mistaken as lockstep with opendal, even when they should be package-specific;
• ecosystem adapters need to follow upstream dependency changes that are unrelated to core development;
• release and documentation workflows become harder to reason about as bindings, core crates, and integrations are mixed together.

The proposed direction is to split ecosystem integrations into separate repository/repositories, while keeping explicit compatibility contracts and documentation discoverability from the OpenDAL website.

Proposed Migration Order

• Decide the target repository layout: one opendal-integrations repository or separate repositories per integration family.
• Define ownership and release policy for split integrations.
• Define versioning policy: integration packages use independent semver and must not imply lockstep with opendal unless explicitly documented.
• Move Spring integration first, since it has an independent Maven/Spring build and release model.
• Move dav-server-opendalfs, unftp-sbe-opendal, and parquet_opendal after the repository and release workflow are ready.
• Move object_store_opendal with extra care because it is a high-impact bridge into the Rust data ecosystem.
• Keep downstream/compatibility validation for important adapters, especially object_store_opendal, when core APIs change.
• Update OpenDAL website docs so users can still discover supported integrations from the main project site.
• Update release tooling so core releases no longer publish split integration packages.
• Update CI, Dependabot, docs generation, and behavior-test workflows that currently reference integrations/** paths.
• Preserve issue/PR/history references or provide clear migration links from the old paths.

Non-Goals

• This issue does not propose changing OpenDAL's core public API.
• This issue does not propose moving services, layers, testkit, or behavior tests out of the core repository.
• This issue does not require all integrations to share one release cadence.
• This issue does not require object_store_opendal to remain version-aligned with opendal.

Acceptance Criteria

• Integration packages are maintained outside the core repository with clear repository ownership.
• Each split integration has documented compatibility expectations with supported opendal versions.
• OpenDAL core release workflows no longer publish integration packages directly.
• Core CI keeps only the compatibility checks that are intentionally required for core changes.
• Users can find integration documentation from the OpenDAL website after the split.