Use obspec exceptions at runtime

[kylebarron]

Closes #342, closes #338. Also closes #199 because the obspec exceptions use multiple inheritance.

Depends on developmentseed/obspec#5

As described below, there's a core issue with this because we'd need to use the exception classes from obspec in pyo3-object_store for the store builders, but we don't want pyo3-object_store to know anything about obspec.

[kylebarron]

I got myself into a total mess 🫠 . I've been trying to do a little refactoring for obstore to make the interface generic, as obspec.

I was looking at the obstore Zarr-Python PR, and I realized we would need to have common exceptions classes, because you might need to have some way to allow a file not found, or something like that. And you'd need to figure out a way to have a common base exception that you can allow.

But then I hit the issue that the base exceptions from obspec would need to be known by the core pyo3-object_store crate, which contains the store builders, because the exceptions defined there would need to subclass from the obspec ones. But I don't really want that because then other rust-python libraries using pyo3-object_store would have to depend on obspec.

So then I thought, I'll manage the exception conversion in the obstore Python layer binding, but then that's super confusing to do.

At the core this is a tug between structural and nominal subtyping. Using protocols instead of subclasses makes this kind of subtyping easier, especially from the Rust side, because the Rust code only has to implement the same shaped interface. The Rust code doesn't need to depend on a specific Python library and subclass from it.

But as far as I know there's no way to do exceptions subtyping with structural subtyping; you can only subclass it.

[kylebarron]

Though one thought I just had is that it's ok if only the "runtime" exceptions subclass from obspec, and not also the "builder" exceptions.

That's maybe a little confusing though.