BUG: fix inheritance in unyt_array.__pow__

[neutrinoceros]

This change is a solution to a downstream issue in yt:
yt-project/yt#4023

it's a direct follow up to #204

I'm not 100% sure it's the right solution, as I don't understand the original implementation using __array_func__, so maybe I'm just missing something, in which case the problem should be resolved on the yt side instead.

@JBorrow I know it's been a little while, any chance you could explain your initial implementation please ?

[neutrinoceros]

So I digged a little further and I think I get why it was implemented this way: given arr a unyt_array instance, as of unyt 2.8, the __pow__ protocol was only called for arer**x if x==0, and it's the only case that was problematic (#203). However the situation changes if unyt_array overrides the base __pow__ protocol from np.ndarray, and now __pow__ gets called for every value of x. @JBorrow very likely understood this and chose an implementation that made sense to preserve backward compatibility, redirecting to self.__array_ufunc__ for x != 0.

Subclassing np.ndarray proves however more complicated than expected, and this did not actually preserve backward compatibility as seen in yt yt-project/yt#4023
My corrected implem leaves all responsabilities to numpy and works better in that sense.

While I was researching this problem, I also realised that the __pow__ method normally takes an optional mod argument https://numpy.org/doc/stable/reference/generated/numpy.ndarray.__pow__.html?highlight=__pow__#numpy.ndarray.__pow__
so I "fixed" this too (using quotation marks here because I couldn't find a single working example using this argument, even with pure np.ndarrays)

[JBorrow]

Yes, that's effectively it. Basically, it's not clear what ufunc numpy is actually using when you do a**n, and I chose to use the unyt subclassing incase we overwrote anything. If we don't, then this is fine.

[neutrinoceros]

Thank you very much !
@jzuhone I think this is now ready :)