Propagate and improve handling of HDF5 errors

Sorry for the spam, GitHub is acting up. Pushing branches no longer triggers the CI. Even when I trigger the Lint & Test workflow manually, it stays "queued" indefinitely...

Fix #1570

Thanks to @bmaranville and h5wasm@0.7.2, we can now configure the HDF5 library to throw errors instead of just logging them to the console with console.error. This will hopefully help surface bugs much faster (like the one fixed in #1568).

Another benefit is that we can now take advantage of the propagated errors when it makes sense, like when a compression plugin is not supported, instead of trying to detect the situation ahead of time.

Summary of changes:

I bump h5wasm and configure HDF5 to throw errors
When an error is thrown by HDF5 when reading a dataset's value (or slice):
- I catch the error and rethrow a more readable error with the original HDF5 error as cause.
- If one of the diagnostic entries of the HDF5 error relates to a filter not being available, I use that diagnostic message as the message of the rethrown error; otherwise, I use the fallback message "Error detected in HDF5".
In ErrorFallback, if an error has a cause, I render a details element with a pre containing the cause. This gives access to the original HDF5 error message for debugging purposes.

Of course, we might uncover other HDF5 errors that we'll need to handle more specifically; this just provides robust foundations. I'm also planning to wrap other h5wasm calls with try/catch (like when reading attributes) in my next PR.