fix: incorrect table data disk cache key

[dantengsky]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Range returned by merged reading should not be used as the corresponding parts of table data cache key,
instead offset and len of column meta should be used.

range.start is not stable and can vary for the same column depending on the query's projection.

For instance:

• SELECT col1, col2 FROM t;
• SELECT col2 FROM t;

may result in different ranges for col2, this can lead to cache missing or INCONSISTENCIES

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Ensure consistent cache key through code refactoring.

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[what-the-diff]

PR Summary

• Improved Stability of Cache Key Generation for Columns
  • The way the keys are created to store our data in a quicker-to-access format (cache) has been updated. Instead of using the less reliable start and end range, we now use a more consistent method involving 'offset' and 'length' details coming from our column information. This change enhances the reliability of storing and retrieving cached information.
  • To ensure this new approach is understood and maintained in the future, detailed comments have been added. This will help avoid inconsistencies in the quick-access data due to changing ranges based on different columns being used.