Allocators in `BTreeMap` and `BTreeSet` need more work

In https://github.com/rust-lang/rust/pull/157428, we banned allocators from unwinding out of their drop to fix #159334 and its related issues. We also introduced AllocatorClone to fix #156920. In #161684, we replaced the Allocator + Clone bounds with AllocatorClone as a short-term solution.

However, the allocators are still cloned at every recursive call site, which was originally done to fix regressions with using references for this, since ZST allocators (like the most important allocator, Global), had measureable overhead. However, for non-Copy allocators, this is completely unreasonable. Even the destructor of BTreeMap clones around the allocator recursively, so there is no way to use BTreeMap without AllocatorClone at all currently.

We should probably come up with another solution that allows ZSTs to be passed by-value, while expensive-to-clone allocators can be passed by reference, perhaps through some kind of unsafe trait AllocatorShare { type Share<'a>: Allocator; fn share_alloc(&self) -> Self::Share<'_>; }. This would also allow something like Box<Arc<&Arc<A>>> to be passed around as A::Share, since it can defer recursively. However it has its own design problems.

Discussion on zulip

@rustbot label A-allocators requires-nightly -I-unsound A-collections -C-bug C-discussion

The issue concerns allocator handling in BTreeMap and BTreeSet, with context in PRs #157428 and #161684, the related issues, and the linked Zulip discussion. Start by tracing the recursive allocator clone sites and the destructor path. Done requires a settled design and implementation that addresses expensive allocator cloning while preserving ZST behavior.