Generalize path parameter extraction beyond the core STAC layout

## Motivation

This is a feature request motivated to support endpoints beyond the core STAC API spec. These endpoints might include ones from the wider ecosystem (e.g., https://github.com/stac-api-extensions/aggregation or https://github.com/StacLabs/multi-tenant-catalogs), or for custom endpoints that users may have added. It would be excellent to be able to use just `stac-auth-proxy` as the one approach for authorizing core, extension, and arbitrary endpoints.

## Description

There is already support for covering arbitrary endpoints via the regexes in `collections_filter_path` and `items_filter_path`, but the `utils.requests.extract_variables` hard codes the extraction of `collection_id` and/or `item_id` to specific core API spec paths.

We can cover arbitrary paths, but the filters we build and use with `Cql2BuildFilterMiddleware` against these paths won't receive any useful data because the regexes for path extraction are hard coded to cover the core STAC API spec endpoints.

This feature request is a `n>1` case extension of #204 which adds `n=1` support for `/collections/{collection_id}/queryables` to the regex extraction.

## Proposed Implementation Details

I think of the `[collections|items]_filter_path` settings that define which paths to cover as coupled to what information should be extracted, so I would be inclined to have these settings control both.

To keep this backwards compatible we could keep the current implementation in `utils.requests.extract_variables` as a default pathway. However, if users provide regex capture groups within `[collections|items]_filter_path` we could use those instead of the hard coded `utils.requests.extract_variables` implementation that works great with the core spec API paths.

Using `collections_filter_path` as an example:

- `r"^/collections(/[^/]+)?$"` (current default) would fall back to `utils.requests.extract_variables` for variable extraction
- `r"^/collections(?:/(?P[^/]+))?$"` has a named capture group (``) that would be used for variable extraction

This could enable support for non-core paths like the aggregation STAC API extension via:
```
COLLECTIONS_FILTER_PATH='[
"^/collections(?:/(?P[^/]+))?$",
"^/collections/(?P[^/]+)/aggregate$",
"^/collections/(?P[^/]+)/aggregations$"
]'
```

---

I also considering building an entirely new middleware to cover arbitrary endpoints, but I abandoned that because I think it would be a better user experience to make the existing `Cql2BuildFilterMiddleware` more fully featured.

Happy to submit a PR to iterate over if this sounds close to reasonable, or also happy to try implementing other ideas! Thank you 🙇

Start in utils.requests.extract_variables and trace how Cql2BuildFilterMiddleware uses collection_id and item_id for filters. Compare the default collections_filter_path and items_filter_path behavior with named capture groups, then verify that custom paths provide the captured values while core STAC paths remain backwards compatible.

Written by the indexing model from the issue text.