ENH: ensure yt.utils.funcs.ensure_numpy_array consistently returns a copy

[neutrinoceros]

PR Summary

I noticed this function could be heavily simplified, but also, and perhaps more importantly, that its return type would sometimes be a copy of the input data, but not always. This looks like a footgun so I'd rather make it always return a copy, so as to avoid subtle bugs.

PR Checklist

• New features are documented, with docstrings and narrative docs
• Adds a test for any bugs fixed. Adds tests for new features.

[matthewturk]

Wait, hold up. I'm not sure that we want this behavior. Making copies of every array that goes into cython is potentially going to lead to an enormous amount of memory churn and reallocation.

[neutrinoceros]

to be clear, the only inputs where the existing code doesn't copy already are

• a list/tuple of non-numeric Python objects (say, strs), in which case it'll return an array of pointers (dtype=object)
• scalars items (either non-arrays or single-value arrays)

[matthewturk]

dang, that's brutal. One of the biggest costs of ghost zones, last time I looked, was around copying and recopying arrays and checking that they were in the right units. But I suppose this probably isn't in that category.

[neutrinoceros]

so if we don't want this to copy, that's a change in behavior in most cases, and I don't think it's one that's safe to make (people's code is going to break in subtle ways).
I'd suggest introducing some new API (either a brand new function, or adding a copy kwarg to this one) if there are applications where we definitely don't want copies.

[matthewturk]

nah it's fine, you pointed out that I was interpreting the change incorrectly.

[neutrinoceros]

CI revealed that np.asarray didn't have a copy argument before numpy 2.0. I could work around this at a local level, but incidentally, I'm adding a general mechanism for handling this problem gracefully across the board in #5307, so I'd prefer to re-work this PR once #5307 goes in.

[neutrinoceros]

Actually it was easy enough to bring only the backward-compatibility layer from the other PR, so I plan to undraft this after the on-going round of CI.

[neutrinoceros]

even better; I can actually write this in a way that always copy and doesn't need a backward compatibility layer at all.

[chrishavlin]

LGTM, based on the discussion above with @matthewturk I think this one is good to merge.