Improve handling of HDF5 errors

[axelboc]

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.

Filter not registered

With dataset sz3 in filters.h5:

• http://localhost:5173/h5wasm?url=https%3A%2F%2Fwww.silx.org%2Fpub%2Fh5web%2Ffilters.h5
• https://h5web.panosc.eu/h5wasm?url=https%3A%2F%2Fwww.silx.org%2Fpub%2Fh5web%2Ffilters.h5

Fallback error

Same file as above, but after commenting out the detection of filter-related errors.

No more error for fcidecomp dataset

Before/after screenshots that show that our attempt at predicting when a filter was not supported was causing false positives: