Fix writing metadata in `prz` file

[ericpre]

Describe the bug

Following #459, there are two things that should be improved:

• the axes metadata doesn't seem to be written correctly when saving to prz
• add write support for prz version >=24.03

@tensionhead, @gguzzina, could you please help with these?

To Reproduce

Steps to reproduce the behavior:

import hyperspy.api as hs
import numpy as np


fname = "test.prz"

s = hs.signals.Signal2D(np.arange(20*50).reshape((20, 50)))
s.axes_manager.signal_axes.set(scale=0.5, units="nm")
s.save(fname)

s2 = hs.load(fname, allow_restricted_pickle=True)

# the scale and units are incorrect in `s2`
assert s.axes_manager.as_dictionary() == s2.axes_manager.as_dictionary()

Python environement:

• RosettaSciIO version: 0.11.0
• Python version: 3.12

[tensionhead]

@ericpre this bug apparently is older than #459, I just checked out rosettasciio v0.10.0 and after removing the allow_restricted_pickle flag the assertion also fails:

import hyperspy.api as hs                                                                                     
import numpy as np                                                                                            
import rsciio                                                                                                 
                                                                                                              
print(f"{rsciio.__version__}")                                                                                
                                                                                                              
fname = "test.prz"                                                                                            
                                                                                                              
s = hs.signals.Signal2D(np.arange(20*50).reshape((20, 50)))                                                   
s.axes_manager.signal_axes.set(scale=0.5, units="nm")                                                         
s.save(fname)                                                                                                 
                                                                                                              
# s2 = hs.load(fname, allow_restricted_pickle=True)                                                           
# before #459                                                                                                 
s2 = hs.load(fname)                                                                                           
                                                                                                              
# the scale and units are incorrect in `s2`                                                                   
assert s.axes_manager.as_dictionary() == s2.axes_manager.as_dictionary() 

Which is a bit surprising, as there are quite some tests for the save/load cycle, but apparently they did not check for this axes_manager property.

Nevertheless I am happy to help here, but before we maybe should discuss the usefulness of saving prz with hyperspy. After discussions also with @gguzzina we concluded that maybe only supporting prz loading is sufficient. As ppl can always just use panta rhei directly if they want to also write prz. Especially as a true OSS Panta Rhei release is now imminent.

Another thing to consider is that to get rosettasciio fullly compatible with the soon to be released Panta Rhei 0.25, yet still support loading legazy prz but writing Panta Rhei >= 0.24.3 prz, we would need to add some nested serialization logic which is in an alpha state at the moment. So my suggestion would be to disable writing prz with hyperspy at least until the serialization problem is solved and stable in Panta Rhei itself.

[ericpre]

I don't use this format, but my general view is that where easily possible (i.e. without much effort), we should try to support as much of the features as possible and we should aim to support interoperability as much as possible - being able to write to a format using the same API is convenient for the user.