Stabilize btree_entry_insert feature

[Kivooeo]

This stabilises btree_map::VacantEntry::insert_entry and btree_map::Entry::insert_entry, following the FCP in tracking issue.

New stable API:

impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> {
    pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>;
}

impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> {
    pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>;
}

(FCP ended almost a year ago, so if it's needed for process we could rerun it)

Closes: #65225

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ibraheemdev]

r? libs-api because it's been a while since the FCP.

[tgross35]

I haven't looked but it's worth a sanity check if the concerns that caused HashMap::insert_entry to be destabilized also apply to BTreeMap #90345 (comment). (It was eventually stabilized after #44286 went through FCP to reject.)

[tgross35]

@rustbot label +I-libs-api-nominated
r? libs

[jhpratt]

r=me assuming someone from T-libs-api is fine with it. It's already passed FCP, but it was roughly a year ago. I see no reason this shouldn't be merged as a result.

cc @rust-lang/libs-api

@bors rollup

[the8472]

We briefly discussed this, seems fine.

[jhpratt]

In that case @bors r+

[bors]

📌 Commit b5a4e5d has been approved by jhpratt

It is now in the queue for this repository.

[jhpratt]

@rustbot label +relnotes