HUH: ``squeeze``ing scalars

I wasn't sure if this should be an "ENH", "BUG", "TYP", "DEP", or "MAINT", so I opted for the sound that came out of my mouth when I first encountered this. Feel free to change it to one of those if you feel like it.

This just made me "huh" out loud:

>>> np.squeeze(1)
array(1)
>>> np.squeeze(np.array(1))
array(1)
>>> np.squeeze(np.int_(1))
np.int64(1)

So "scalar-likes" are not treated equally; some return numpy scalars, others return 0d arrays.

Besides this increasing the ever so important "huh/sec" rate [^1], it's also pretty annoying to express in the stubs. But before you panick and/or call the press, the squeeze stubs aren't incorrect [^3] [^2], so it's not that big of a disaster.

Anyway, given the array-api's lack of scalar-types, and them being infuriatingly annoying for static typing, I think that I'm slightly leaning towards choosing 0d-arrays over scalars here. I.e., changing squeeze so that it always returns an instance of numpy.ndarray (or a _subtype thereof), even if you pass it a np.generic scalar-type thingy.

This would technically be a backwards-incompatible breaking change. But, considering that 0d arrays are mostly duck-type compatible, and that I don't see why anyone would want to squeeze their scalars in the first place, I doubt that many will be bothered by this change.

[^1]: Is that a thing? Well, if it isn't; then I think it should.
[^2]: they're technically not correct either, seeing as it can return Any
[^3]: which, given the lack of comment about it, might just have been a "happy little accident" (🎨)

TLDR; Let's have numpy.squeeze always return an array

Start by reviewing the squeeze stubs in numpy/_core/fromnumeric.pyi and reproduce the scalar examples from the issue. Trace the current squeeze behavior for Python scalars, 0d arrays, and np.generic scalars before deciding whether a consistent return type is appropriate. Done requires an agreed API direction, implementation, updated typing, and coverage for the demonstrated cases.