Tighten up some ArrayPool.Return usage

[stephentoub]

Avoid potential problems if Return were to throw an exception after having already put the array back into the pool.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[MihaZupan]

If we're guarding most of our usages like this, would having a Return(ref T[]? array) API make sense (letting that method null out the reference for the caller)?

[GrabYourPitchforks]

@MihaZupan Was thinking the same thing, but then we'd also have to teach people the difference between the two methods, including potentially even having analyzers for this. And if we ever do get a proper lifetime management feature in the language, it's all moot anyway.

Would a more straightforward alternative be to say "implementations of ArrayPool<T>.Return may check for usage errors and throw exceptions in those scenarios, but otherwise the methods must succeed"? If CERs were still a thing I imagine that's how we would have annotated this API, considering at its heart it is a manual resource management API.