Fix BaseExtraList::RemoveExtra leaving _tail inside the removed node

[ejams1]

BaseExtraList::_tail points at the last node's next field (AddExtra does *_tail = a_extra; _tail = &a_extra->next). In a consistent list *_tail is therefore always nullptr, so the check in RemoveExtra never holds:

if (!_tail || *_tail == iter) {

When the removed node is the last one, which is the usual position for a non-high-use type such as ExtraInstanceData, _tail is left at &removed->next. The next AddExtra of a non-high-use type writes through it, into a node that is no longer in the list. If that node is the one just removed (remove, try to rebuild, put the old one back), it ends up pointing at itself. BaseExtraList::RemoveAllDefault then walks a cycle on the next revert. With one allocator it frees the same block forever; with the stock heap it calls through the freed object's cleared vtable (Fallout4.exe+0272571 call [rax]).

The change:

• The test is _tail == std::addressof(iter->next), so _tail moves back to prev->next (or _head) exactly when the last node is removed.
• The removed node's next is cleared. A node removed from the middle still pointed into the list, so handing it back to AddExtra (which asserts next == nullptr) would link the rest of the list behind it.

We found this through a plugin that refreshes reference instance data with RemoveExtra(kInstanceData) and re-adds the old node when the rebuild fails. Every save load then hung or crashed in RemoveAllDefault.