Provider `get_historical_features` API cleanup: remove ad-hoc args and formalize ODFV handling

### Context
PR #5803 adds a new argument `on_demand_feature_views` to `Provider.get_historical_features`.

This fixes a gap where `FeatureStore.get_historical_features()` already resolves which `OnDemandFeatureView`s are requested (via `_group_feature_refs`), but historically that list was not explicitly passed to the Provider. Some provider implementations / compute engines benefit from receiving the requested ODFVs explicitly (planning/optimization/correctness without re-deriving).

A maintainer requested tracking this as an interim change and flagging a proper long-term interface fix.

### Problem
The historical retrieval interface currently encourages “API drift”:
- `FeatureStore` performs grouping/selection of requested feature views vs ODFVs
- Providers/offline stores may need to re-derive ODFV selection from `feature_refs` and registry state
- New requirements tend to be implemented via ad-hoc argument additions to `Provider.get_historical_features`

This makes the contract unclear and can lead to duplicated logic or unnecessary work in providers.

### Goal
Define a clearer long-term contract for historical retrieval that:
- makes the retrieval request structure explicit (including requested ODFVs / transformations)
- avoids one-off arguments in the Provider API
- reduces duplicated grouping/selection logic between `FeatureStore` and providers
- supports compute-engine-style providers planning execution deterministically

### Proposed direction (non-binding)
One of:
1. Introduce a typed request object (e.g. `HistoricalRetrievalRequest`) passed into Provider/offline store, containing:
- resolved `FeatureView`s
- resolved `OnDemandFeatureView`s / transformations
- `feature_refs`
- entity dataframe/query or time range params
- `full_feature_names`, project/config, etc.
2. Alternatively, formalize that `feature_views` includes both FVs and ODFVs in a consistent way, and remove the need for a separate `on_demand_feature_views` parameter (with a documented contract for how they’re represented and used).

### Acceptance criteria
- API: A documented, stable Provider/offline-store historical retrieval interface (request object or equivalent).
- Refactor: Avoid future ad-hoc args like `on_demand_feature_views` being added to `Provider.get_historical_features`.
- Compat: Clear backward compatibility / deprecation plan for existing providers.
- Tests: Unit/integration coverage proving:
- requested ODFVs are correctly resolved and passed through
- providers can plan execution without re-deriving ODFV selection

### Related
- PR: #5803