feat(storage): support Jindo for OSS scan planning

[XiaoHongbo-Hope]

Purpose

Allow Rust scan planning to use an installed JindoSDK for OSS metadata and index reads. OpenDAL remains the default backend; select Jindo with fs.oss.impl=jindo.

PyPaimon can opt its read-only native-planning catalog into this backend automatically through apache/paimon#9124.

Changes

• add an optional storage-jindo feature selected by fs.oss.impl=jindo
• dynamically load the Jindo C ABI without bundling an SDK binary
• support object stat, ranged reads, suffix reads, full reads, and recursive listings
• initialize Jindo lazily and run SDK initialization and I/O on Tokio blocking workers
• discover the SDK through an explicit path, environment variables, JINDOSDK_HOME, or an installed pyjindosdk package
• fail explicitly for unsupported writes, deletes, and copies

Validation

• 5 Jindo storage tests
• Python SDK discovery test
• default OSS and storage-jindo feature builds
• Clippy with warnings denied, formatting, and diff checks
• read-only end-to-end validation against an OSS-backed REST catalog:
  • listed snapshots and an empty tag directory
  • planned and read the expected row with 1 split / 1 file

Notes

No JindoSDK binary is linked or packaged by this project. Explicitly selecting Jindo without the feature or a loadable SDK returns a configuration error. Jindo is currently a read-only backend; writes continue to use the default OpenDAL backend unless Jindo is explicitly selected.

[JingsongLi]

Have you compared Jindo and OpenDAL? What are the differences? (benchmark)