Add extend_from_array

[scottmcm]

This PR inspired by noticing that the following, while it seems reasonable, actually contains 4 calls to reserve in the ASM:

pub fn push3_demo(v: &mut Vec<i32>, a: i32, b: i32, c: i32) {
    v.reserve(3);
    v.push(a);
    v.push(b);
    v.push(c);
}

https://rust.godbolt.org/z/EWExYP

Like there's extend_from_slice for cloning, it seems like it would be logical to have an extend_from_array to encapsulate the obvious unsafe code for moving the elements to the end of the vector. And, indeed, that turns out to generate tighter assembly than any of the other options I tried, including array::IntoIter and chains-of-onces: https://rust.godbolt.org/z/Wq7qah

I ended up putting this on Extend, as it makes particular sense on anything that can take advantage of the memory continuity of the array -- this PR implements it for Vec and VecDeque -- but would also be handy as a way to tersely add a known number of elements to any collection by move. It has the nice default implementation in terms of the array IntoIter, so that things without special overrides for it can still do something reasonable, as that provides an exact size_hint.

But touching a trait means it should probably get some libs eyes on it even to go in unstable, so let's try
r? @m-ou-se

(A different approach for this could be something like push_chunk, in the sense of as_chunks.)

[scottmcm]

(Hmm, that codegen test passed locally. I'll leave it for now, and fix it along with adding a tracking issue if this gets a "seems plausible".)

[scottmcm]

Thanks, @erikdesjardins! That sounds plausible.

And because that means this might fail in bors even after passing CI,
@bors rollup=iffy

[m-ou-se]

The implementation looks good to me, but once IntoIterator is implemented for arrays (#65819), v.extend_from_array([1, 2, 3]) would be equivalent to just v.extend([1, 2, 3]), making this new api redundant, right? (Maybe with a specialization or two in its implementation.)

[m-ou-se]

There's a safe way to get the end pointer: self.as_mut_ptr_range().end

[bors]

☔ The latest upstream changes (presumably #80138) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[scottmcm]

I'm not going to be able to look at this for a bit, with edition stuff being higher priority. I'll close for now, and maybe will reopen as not a trait method in the future.