BUG: incorrect promotion of scalars in logspace

[seberg]

gh-23275 added broadcasting before the promotion happened, which is incorrect for 0-D objects as they may have special promotion rules (value-based or Python int/float/complex being special).

First reported at cupy/cupy#7946

Ping @byrdie since it was your PR.

[byrdie]

@seberg, thanks for the ping, do you know what the best fix might be? Seems like we need to avoid a call to np.array() right?

[seberg]

At the moment the issue is the broadcasting and not the asarray(). In the future, we could just broadcast bins (and thus convert to array) if it isn't a python int/float/complex (not sure complex makes sense at all).
That is, right now 0-D objects/arrays are "special", in the future Python int/float/complex would be (but not our 0-D objects).

We should probably turn around the logic simply. Convert base to an array (doesn't hurt much anyway), but only ever call the broadcasting step when base is not 0-D.

There is another little thing that Marten might complain about anyway, that this uses asarray() and that loses subclass info (although these days that is probably less relevant due to __array_function__). asanyarray() would be better.

(May need another bit of thought, but hopefully it helps and if you think about it also and reach similar conclusions we are good).

[rgommers]

Leaving the 2.0.0 milestone for now since it's type promotion related, but this doesn't seem blocking.

[mhvk]

Fix in #25919.