add Future.copy! function

[rfourquet]

This implements the suggestion proposed in #24808 to have Future.copy! available in Base right now, which will be moved to Base for 1.0. Unfortunately, the name Future is already taken, so I temporarily named it Next till a decision is taken for the name.

I implemented this new version of copy! in a conservative way: copy!(a, b) works only if a and b are in the same abstract hierachy, i.e arrays with arrays, sets with sets etc. We could be even more strict by requiring a and b to be of the same type, but that doesn't seem useful. One caveat is that we don't necessarily have a==b after the call, because for example [1, 2] != 1:2 or Set(1) != BitSet(1). But my understanding is that we would like to have these examples be equal.

A less conservative approach would be to allow copying any iterable into the destination, but I feel this is much more debatable, as in this case there is no way we will have equality of a and b after the call, e.g. in copy!(rand(2, 3), rand(3, 2)), the 2 arguments don't have the same shape. Or in copy!(Set(1), rand(2, 3)) we don't even have the same kind of collection. My feeling is that this use-case is kind of in between copy! and copyto!, so I would prefer to not rush with this one and take the time to think about it. In the meantime, it's seems enough to suggest simple alternatives, like union!(empty!(Set(1)), rand(2, 3)), or copyto!(rand(2, 3), rand(3, 2)).

[GunnarFarneback]

Misspelling of consider. And isn't it rather "same size" than "same dimension"?

[fredrikekre]

FWIW I like Future better than Next, you seem to have used both names in this PR.

[StefanKarpinski]

I like Future better as well (and it has precedent from Python).

[rfourquet]

I also definitely prefer Future, but as I said it's "taken" (now it's @deprecate_moved into "Distributed"), so the compilation fails with Future instead of Next.

[rfourquet]

So I hadn't thought about it earlier, but making Future an stdlib package instead of a Base submodule doesn't seem to create conflict with the current Base.Future deprecated name. If CI passes, it would be good to go I believe.

[rfourquet]

I will merge some day next week, if no objection and no one beats me to it.

[GunnarFarneback]

Consider is still misspelled.