PR #2175: Fix use-after-free in linked_hash_set and linked_hash_map move assignment

Imported from GitHub PR https://github.com/abseil/abseil-cpp/pull/2175

## Issue

Fixes #2174.

`linked_hash_set` and `linked_hash_map` move assignment with an unequal,
non-propagating allocator leaves the internal `flat_hash_set` of `std::list`
iterators pointing at the source's nodes, which the source then frees
(`heap-use-after-free`; SIGSEGV without a sanitizer). For
`linked_hash_map` the same configuration does not compile at all.

## Root cause

`operator=(linked_hash_set&&)` (and the map equivalent) unconditionally did

```cpp
set_ = std::move(other.set_);
list_ = std::move(other.list_);
other.set_.clear();
other.list_.clear();
```

When `propagate_on_container_move_assignment` is false and the allocators
compare unequal, `std::list` cannot take over the source's nodes and
re-creates them with the destination's allocator, so the iterators taken
over with `set_` dangle as soon as `other.list_.clear()` runs. `std::list`'s
move assignment additionally element-assigns in that case, which does not
compile for the map's `std::pair<const K, V>` value type.

## Fix

Dispatch on `propagate_on_container_move_assignment`:

* **true**: propagate the allocator and use the component moves as before;
* **false, equal allocators**: take over the nodes with `clear()` +
  `splice()` (splice relinks the nodes instead of element-assigning, which is
  also what makes this compile for the map);
* **false, unequal allocators**: move each element into a new node allocated
  with the destination's allocator and rebuild the index over those nodes
  with the source's hash and equality state, mirroring
  `raw_hash_set::move_assign`.

The operator is no longer unconditionally `noexcept`; it now uses the same
specification as `raw_hash_set::operator=(raw_hash_set&&)`:
`is_always_equal && is_nothrow_move_assignable<hasher> &&
is_nothrow_move_assignable<key_equal>`. This is an API change for callers
whose allocator is not always equal: the operator can now allocate and
throw. It can be split out of this change if preferred.

## Tests

Three tests in `linked_hash_set_test.cc` and three in
`linked_hash_map_test.cc`, in the style of
`ExtractAndEmplaceUseSameStatefulAllocator`. Unequal allocators come from
`CountingAllocator` instances with different state pointers, and
`MoveAssignPropagatingCountingAlloc` provides a propagating allocator:

* `MoveAssignWithUnequalNonPropagatingAllocator`: empty and non-empty
  destinations; checks `contains`, `find`, `erase`, iteration order, that the
  destination's old elements are gone, and that the source is empty;
* `MoveAssignWithEqualAllocatorTakesOverNodes`: the nodes and the index are
  taken over without allocating;
* `MoveAssignWithPropagatingAllocatorPropagates`: the allocator is
  propagated even when the allocators are unequal.

## Verification

* New tests, unpatched: the set test aborts under ASan with
  `heap-use-after-free` (`Wrapped::operator()` at `linked_hash_set.h:98`,
  reached from the test at `linked_hash_set_test.cc:878`) and SIGSEGVs
  without a sanitizer; the map test does not compile (`std::list` element
  assignment of `std::pair<const int, int>`).
* New tests, patched: pass, plain and ASan.
* Full suites, patched: `linked_hash_set_test` 219/219 (plain) and 218
  passed + 1 skipped (ASan); `linked_hash_map_test` 341/341 (plain) and 340
  passed + 1 skipped (ASan); `raw_hash_set_test` and
  `raw_hash_set_allocator_test` pass under ASan (no fallout).
* The control/trigger PoCs from the issue pass with the patch under both
  libstdc++ (clang 14) and libc++ (clang 22).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Merge e0a08bbe766042f88cebc12d4b0f6491699c73c3 into e7d5000d632dc1c3f32477b027bf0384b1747325

Merging this change closes #2175

PiperOrigin-RevId: 991220704
Change-Id: I501a52d9ae51da76934e8c9f38176d5b227f015c