Dimension when Scalar axis

[to266]

as it was noted first in #517, 0d signals (or, more specifically, 0d data) could not be saved by our hdf5 writer, as it required the thing to be "sliceable". Instead of modifying the writer, we then decided that hyperspy should not support 0d signals, and #622 made an attempts to fix it (which was not complete, and I will PR to supplement it shortly).

However the #622 solution shows a couple of inconsistencies:

if there exists a navigation axis, we can get rid of the last signal axis. If we later (for example) sum over the last navigation axis, we instead "swap" it to a new signal axis and call it "scalar":

In [1]: s = hs.signals.Signal(np.arange(15).reshape(3,5))

In [2]: s
Out[2]: <Signal, title: , dimensions: (3|5)>

In [3]: s.sum(0)
Out[3]: <Signal, title: , dimensions: (|5)>

In [4]: s.sum(1)
Out[4]: <Signal, title: , dimensions: (3|)>

In [5]: s.sum(1).sum(0)
Out[5]: <Signal, title: , dimensions: (|1)>

This is confusing, and inconsistent, as (to begin with), if we have a scalar axis, then navigation with no signal just does not make sense. The axis dance itself (1|1 -> 1|0 -> 0|1) does not help to clear things up.

As @francisco-dlp already suggested, a better and more consistent way would be to introduce a new type of "scalar" axis. For all intents and purposes it should not be sliceable and plottable (if only a scalar is left with no navigation, we should print the number instead. If a navigation axis exists, only navigator plot should be plotted).

I had a quick attempt at just preventing the hyperspy removing the last signal axis and instead replacing it with one just named "scalar", however that broke most of the slicing, so I guess it calls for a less hacky solution..

Anyway, the two possible ways to solve it are:

• implement a proper scalar axis
• modify the hdf5 writer so that it can save scalars as well.

If we think that current hyperspy (with 0d signals and no scalar axes) is consistent and makes sense, fixing the writer would be much quicker and easier

[to266]

An attempt to fix the actual problem (i.e. saving the 0d signal) can be found here: #645

We can just ignore it if in the end we decide to implement scalar axis properly.. However at the moment I think it's better to actually fix the problem and not patch it up with an incomplete implementation that also makes a couple of things somewhat confusing