Reducelikes should have lived in the future where the `out` dtype
is correctly honoured always and used as one of the *inputs*.
However, when legacy fallback occurs, this leads to problems because
the legacy code path has 0-D fallbacks.

There are two probable solutions to this:
* Live with weird value-based stuff here even though it was never
  actually better especially for reducelikes.
  (enforce value-based promotion)
* Avoid value based promotion completely.

This does the second one, using a terrible hack by just mutating
the dimension of `out` to tell the resolvers that value-based logic
cannot be used.

Is that hack safe?  Yes, so long nobody has super-crazy custom type
resolvers (the only one I know is pyerfa and they are fine, PyGEOS
I think has no custom type resolver).
It also relies on the GIL of course, but...

The future? We need to ditch this value-based stuff, do annoying
acrobatics with dynamically created DType classes, or something similar
(so ditching seems best, it is topping my TODO list currently).

Testing this is tricky, running the test:
```
python runtests.py -t numpy/core/tests/test_ufunc.py::TestUfunc::test_reducelike_out_promotes
```
triggers it, but because reducelikes do not enforce value-based promotion
the failure can be "hidden" (which is why the test succeeds in a full test
run).

Closes numpygh-20739