Support builtin and numpy types in HDF5

[jl-wynen]

Fixes #3056

[jl-wynen]

How do we handle the version of the file format here? Files with these entries cannot be loaded by an old scipp version. But old files continue to work.

[SimonHeybrock]

I have seen NeXus files that use bytesrings, can we support that?

[jl-wynen]

What do you mean by bytestring? Python's bytes? h5py seems to store str as bytes. This is why the loader calls decode.

[SimonHeybrock]

Yes, bytes, iirc.

[jl-wynen]

Done

[SimonHeybrock]

How do we handle the version of the file format here? Files with these entries cannot be loaded by an old scipp version. But old files continue to work.

We have so far not done any version checks on files, have we?

[jl-wynen]

How do we handle the version of the file format here? Files with these entries cannot be loaded by an old scipp version. But old files continue to work.

We have so far not done any version checks on files, have we?

We encode a version in the file but we don't actually check it for some reason.

[SimonHeybrock]

How do we handle the version of the file format here? Files with these entries cannot be loaded by an old scipp version. But old files continue to work.

We have so far not done any version checks on files, have we?

We encode a version in the file but we don't actually check it for some reason.

It was added as a way of keeping that option open in the future. Maybe we should?

[jl-wynen]

We encode a version in the file but we don't actually check it for some reason.

It was added as a way of keeping that option open in the future. Maybe we should?

Unfortunately, it stores the scipp version not a version of the format. As far as I can tell, when loading a file with an old version, there is no way to check if the file comes from a new, incompatible version of scipp.
If we want such a feature, we should implement support separately from this PR.