refactor indexing.py: introduce .oindex for Explicitly Indexed Arrays

[andersy005]

this pull request represents an initial effort to refactor the indexing logic within indexing.py by separating it from variable.py. to enhance the flexibility of explicitly indexed array classes, this PR introduces orthogonal and vectorized indexing methods—.oindex[key] and .vindex[key[. these changes are a part of a broader initiative aimed at enabling indexing support for namedarray

• Towards NamedArray tracking issue #8238
• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst
• New functions/methods are listed in api.rst

edit 1:

• to minimize the blast radius of this PR, i decided to just focus on oindex[key] method in this PR. i intend to introduce vindex[key] in a separate PR

TODO:

• refactor indexing.py: introduce .oindex for Explicitly Indexed Arrays #8750 (comment)
• Enable passing the underlying tuple key

[dcherian]

drive-by comment: Our TODO list should include migrating these indexer objects to namedarray/indexer.py or something (eventually)

[dcherian]

Do you know why there are no changes to the backend arrays yet? Those too use *Indexer objects, and we want to break that out. However now I really there's a backwards compatibility problem there. Can you take a look at cfgrib/rioxarray/tiledb-python to see how they use these lazy arrays and indexing please?

[andersy005]

Can you take a look at cfgrib/rioxarray/tiledb-python to see how they use these lazy arrays and indexing please?

after taking a look at the respective repos, it's my understanding both the rioxarray and cfrib projects use the explicit_indexing_adapter function. this function acts a bridge, connecting high-level *Indexer objects with backend-specific indexing methods. thanks to each backend wrapping its BackendArray within a LazilyIndexedArray (which supports the oindex[]), everything functions smoothly since we are still passing *Indexer objects within the xr.Variable.__getitem__. however, i anticipate that modifications will be necessary when we begin to directly pass the underlying tuple to methods like __getitem__, oindex, and vindex within xr.Variable.__getitem__

on the other hand, TileDB-CF-Py seems to bypass this pattern, handling the getitem method differently by using its unique logic for processing the underlying tuple. It still wraps its BackendArray within a LazilyIndexedArray though.

• https://github.com/TileDB-Inc/TileDB-CF-Py/blob/2c041de8e5f6ae585518a7e5276a6f0a5daee3bc/tiledb/cf/xarray_engine/_array_wrapper.py#L153

• https://github.com/TileDB-Inc/TileDB-CF-Py/blob/2c041de8e5f6ae585518a7e5276a6f0a5daee3bc/tiledb/cf/xarray_engine/_backend_store.py#L83-L99

• https://github.com/corteva/rioxarray/blob/e33616e6b35076749605d5c8d0ff7908e257c2a1/rioxarray/_io.py#L452C1-L456C1

• https://github.com/ecmwf/cfgrib/blob/f95912c838a42fbfc26312927a28c8305258ddb9/cfgrib/xarray_plugin.py#L153-L159

cc @dcherian

[dcherian]

Thanks, this generally seems like a step in the right direction