[bugfix] Fix assignment operators for moved-from external-heap tracked_ptrs

[jairov4]

All assignment operators (nullptr_t, const tracked_ptr&, const tracked_ptr<U>&, unique_ptr<U>&&, tracked_ptr&&) now check for moved-from state (where _ptr() returns nullptr) and allocate a fresh Pointer instead of unconditionally calling _ptr()->store(...).

Root cause

When a tracked_ptr<T> lives on the C++ heap (external-heap mode), the move constructor steals the internal Pointer* from the source, leaving its _ptr() null. The original copy/null/unique_ptr assignment operators then call _ptr()->store(...) unconditionally → null-pointer segfault.

This surfaced in std::stable_sort (via libc++'s __insertion_sort_move):
it move-constructs a temporary, then copy-assigns back to the moved-from original.

Fix

Five operators in tracked_ptr now guard the store with if (auto self_ptr = _ptr()) and allocate a new Pointer in the else branch. The move-assignment operators were already safe (they had the guard), but were left unchanged.

Test

Added AssignmentToMovedFromExternalHeap — exercises copy assignment, move assignment, nullptr_t assignment, and unique_ptr assignment to moved-from external-heap tracked_ptrs. All 203 existing tests pass.

Additional fix: static-initialization-order crash in PageInfo<T>::child_pointers

Root cause

PageInfo<T>::child_pointers (in sgcl/detail/page_info.h) was a plain,
eagerly-initialized inline static data member:

inline static ChildPointers child_pointers {!MayContainTracked<Type>::value, ObjectSize};

Unlike its sibling members in the same struct — private_metadata() and array_metadata() — which already use the lazy function-local-static singleton pattern, child_pointers was not lazy, even though its constructor does real dynamic (heap-allocating) initialization via ChildPointers' std::vector<std::atomic<uint8_t>> map member.

This is a textbook static-initialization-order fiasco: if the very first program-wide construction of a tracked type T happens as (or nested inside) another translation unit's own static/dynamic initializer — e.g. a global variable's constructor calling a factory function defined in another TU, whose constructor itself nested-constructs another tracked type — then PageInfo::child_pointers may not yet be dynamically initialized when Maker's "first construction of this type" code path (in maker.h) fills the object's memory with a sentinel and expects child_pointers.map to already be correctly sized. When it isn't, Pointer's constructor hits:

Assertion failed: (offset / 8 < pointers.map->size()), function Pointer, file pointer.h, line 25.