FIX: Make nditer work for 0-d iterations.

There are relatively few changes necessare here. However there is a
conceptionally cleaner fix by not using axisdata at all,
sice the 0-d iterator does not have any axisdata, but on first it
seems it would require more thourough fixes for the buffers, and maybe
even more special cases.

This instead uses one axisdata and just makes sure that it is filled
fine, so that later code can assume that at least one axisdata exists and
has correct pointers to the data.

The dtype transfer functions in lowlevel_strided_loops did not support
ndim=0 as well, so a check is added there.

--

I am really not sure if this is the proper way to fix it or not. Somewhat it would seem nicer to just not use axisdata at all, but thought I would put it out there anyway. Also since the iterator seems to assume that axisdata carries all the important pointers, while they are available elsewhere, that might just be more special cases. (But I mostly reverse engineered which changes made things work, so not sure about the details of nditer). One thing that is not so nice is that probably at some places pointers are carried around inside nditer that must not be used.

These fixes for example:
```python
>>> np.einsum('...,...', 3, 4)
12
>>> i = np.nditer(np.array(-123), op_axes=[()], flags=['multi_index'])
>>> i.next()
array(-123)
```
and makes that ndindex hack unnecessary. valgrind does not report anything that worries me, but of course thorough tests are missing for now.