Improve the soundness of relocating thread_aware::Arc when multiple sources are provided

[martintmk]

I have encountered an issue when relocating thread_aware::Arc and unknowingly providing multiple different source affinities. This caused a bug where I had a "dead instance" caused by multiple relocations.

The problem disappeared where I made sure that only a single source affinity was provided across all relocations calls. Would be nice to provide some debug assertion to ensure caller provides a proper source affinity.

[Darksecond]

Bug: thread_aware::Arc::relocated() corrupts storage when source == destination

In Arc::relocated() (cell/mod.rs line 488), when the source and destination affinities refer to the same slot, the method:

1. Creates a new value via factory and stores it at the destination slot (line 524)
2. Unconditionally stores the pre-relocation self.value at the source slot (line 534) — which is the same slot — overwriting the value just created in step 1

The returned Arc correctly holds the factory-created value, but the shared storage now holds the stale pre-relocation value. Any subsequent relocated() call
targeting that affinity finds the stale value via get_clone(destination) (line 492), silently returning the wrong data.

Fix: Skip the source store when source equals destination:

if let MemoryAffinity::Pinned(source) = source {
if source != destination {
guard.replace(source, self.value);
}
}

Workaround: Callers can pass MemoryAffinity::Unknown as source to bypass the source-store path entirely (the if let Pinned guard is false for Unknown).