feat(API): Implement Backwards Compatibility Layer for Get Range

[walldiss]

Implementation ideas

Maintain backwards compatibility with existing share module for GetRange rpc. Create a backwards compatibility layer to ensure the existing get range functionality continues to work while introducing the new optimized proof structure in separate v1 modules.

Acceptance Criteria

• [ ] Extract new range implementation into share_v1 module
• [ ] Ensure existing share module API remains unchanged
• [ ] Implement adapter layer to convert between old and new proof structures
• [ ] All existing API tests pass without modification
• [ ] New share_v1 module uses optimized dataroot proof structure

Technical Details

• Current get_range in share module should remain as-is
• New share_v1/get_range should use the optimized proof structure
• Implement conversion utilities for proof structure migration

[Wondertan]

Why do we need to keep the old version around? I believe going to places where GetRange is used(mainly Arbitrum nitro integration) and updating it ourselves is gonna be far easier then keeping this baggage around.

[walldiss]

@Wondertan Good question. Breaking changes in range APIs require updates across all integrations. If any integration misses the migration window, we risk production issues.

We will migrate all other methods of share and blob package to new proof structure in follow up issue. Migrating them all at once and with backwards compatability will make it a lot easier for every integration to migrate. Please read EPIC: https://github.com/celestiaorg/celestia-node/issues/4308