new feature: expose Operator::from_uri to other language bindings

### Feature Description

I'm very excited by `Operator::from_uri` as it opens up a lot more options for being generic over storage backends in many tools and bound languages. Great job by everyone involved!

It would be very useful to be able to use this directly from e.g. python.

### Problem and Solution

Currently, if you're allowing a user to specify a storage backend, they need to give the scheme and any operator-specific keyword arguments explicitly, which makes for a broad API (see the many overloads of `Operator.__new__` in python). Having an additional method which takes a URL and arbitrary keyword arguments would open up a lot of flexibility, e.g.

```python
class Operator:
@staticmethod
def from_url(url: str, **kwargs) -> Self:
...

op_url = input("What is the URL of your operator? ")
operator = Operator.from_url(op_url)
```

rather than having to manually parse out the scheme and arguments from a URL in order to use the existing `__new__` method(s).

I'm happy to give this a go if such a change would be accepted.

P.S. I've used URL because it is a locator rather than an identifier and there's no mechanism for mapping a non-URL URI to a location; but we could stick with URI for consistency.

### Additional Context

_No response_

### Are you willing to contribute to the development of this feature?

- [x] Yes, I am willing to contribute to the development of this feature.

Start by tracing the existing Rust Operator::from_uri entry point and the Python Operator.__new__ overloads. Decide whether the exposed binding should be named from_url or from_uri, then make the Python binding accept a URL and keyword arguments and verify that it constructs an operator without manual scheme parsing.

Written by the indexing model from the issue text.