Allow creating a pipeline for ReadMany scenarios

We should allow an SDK to create a query pipeline for a ReadMany scenario. We can do this by adding a new constructor API to `QueryPipeline`: `pub fn for_read_many(item_coordinates: Vec<(String, String)>, pkranges: impl IntoIterator) -> Self`

This API would construct a query pipeline that, when run, will return the requests necessary to fetch the specific items from individual PK Ranges, and yield the items once the responses are received.

As part of this, we'll **also** need to change the API for `DataRequest`. Currently, it has the following definition:

```rust
/// Describes a request for additional data from the pipeline.
///
/// This value is returned when the pipeline needs more data to continue processing.
/// It contains the information necessary for the caller to make an HTTP request to the Cosmos APIs to fetch the next batch of data.
#[derive(Clone, Debug, PartialEq, Eq)]
#[cfg_attr(feature = "python_conversions", derive(pyo3::IntoPyObject))]
pub struct DataRequest {
pub pkrange_id: Cow<'static, str>,
pub continuation: Option,
}
```

As a result of this change, it'll need to get a `query` field that allows each request to use a separate query. However, I think it should be an `Option` so that we don't over-allocate strings for the scenario where the query _is_ constant for each request. When doing a cross-partition query, the gateway rewrites the query into a single query that can be executed against each partition, so returning the query from `DataRequest` is wasteful and would just require cloning `String`s.

So, my proposal for this is to add `pub query: Option` to the field. The SDK should treat this as a nullable string. If the query is `None`/`nullptr`/`nil`/etc. (language-dependent), the SDK will use the Pipeline's default query. If it's `Some` (non-null), then the SDK will use that query.

We probably *also* need to make the `Pipeline::query(&self)` function return `Option<&str>` to indicate scenarios where there _is no single global query_ (such as in a ReadMany).

Start by locating the QueryPipeline, DataRequest, and Pipeline::query definitions and their callers. Trace how requests are produced and how responses yield items, then identify the existing tests for pipeline behavior. Done means ReadMany can create per-item requests, optional queries are handled correctly, and existing cross-partition behavior remains intact.

Written by the indexing model from the issue text.