remove unnecessary generic bounds from Vec::append

[PonasKovas]

Currently Vec::append requires that the other Vec use the same allocator, which is not actually required for the implementation of the method. This PR makes Vec::append accept any Vec<T, B> where B: Allocator.

[rustbot]

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[thomcc]

This seems fine, but I'm going to reassign to someone on the libs-api team.

r? @Amanieu

[kadiwa4]

The disadvantage is that it prevents #56763 from being implemented (unless you can still do it with specialization)

[Amanieu]

The disadvantage is that it prevents #56763 from being implemented (unless you can still do it with specialization)

That's a good point. Since I don't think there is a strong use case for making append accept a Vec<T, B>, perhaps we should avoid doing this.

[thomcc]

FWIW we could do it without specialization by comparing typeids. That said I don't feel very strongly about this.

Edit: Nevermind, that doesn't work because A might not be 'static.