Forcing the output dtype does not work here, since it actually
can be integral (not that this is usually a good idea).
In practice, the change we are doing here is forcing 64bit (or
32bit depending on platform) of precision for the calculation.

This means that the change will only ever increase precision mildly
compared to the current situation.

Small micro-optimization, since using Python integers is generally a bit faster in the loop.
The effect is small, so this could undone if anyone figures it is cleaner the other way.

The array creation functions have the most to gain:

1. np.asarray is 4 times faster and commonly used.
2. Other functions are wrapped using __array_function__ in Python
   making it more difficult

This commit (unfortunatly) has to do a few things:

* Modify __array_function__ C-side dispatching to accomodate
  the fastcall argument convention.
* Move asarray, etc. to C after removing all "fast paths" from
  np.array (simplifying the code)
* Fixup imports, since asarray was imported directly in a few places
* Replace some places where `np.array` was probably used for speed
  instead of np.asarray or similar. (or by accident in 1 or 2 places)

* Fixed  keyword bug

* Added test case

* Reverted to original notation

* Added tests for var and std

Closes gh-18552

This removes a 20%-30% overhead, and thus the largest chunk of
slowdown incurred by adding the `where` argument. Most other places
have fast-paths for `where=True`, this one also should have it.

The additional argument does slow down the function versions a bit
more than this, but that is to be expected probably (it has to
build a new argument dict, at some point we might want to move this
to C, but that seems worth much more with FASTCALL logic).

Harmonize the signature of np.mean, np.var np.std, np.any, np.all,
and their respective nd.array methods with np.sum by adding a where
argument, see gh-15818.