What does this PR do?

Closes #11500
Closes #17372

• Fixes the ambiguous warning "Can't get component (type: EditorSequenceComponent, addr: ?) entity ID as it is not attached to an entity yet!" in the Component::GetEntityId() generated in the EditorSequenceComponent::RemoveEntityToAnimate(() while destroying an instance when sanitizing a prefab DOM;
• • No side-effects.

--

• Fixes the ambiguous warning "The dirty entity has no owning instance." in the PrefabPublicHandler::GenerateUndoNodesForEntityChangeAndUpdateCache() generated while destroying an instance when sanitizing a prefab DOM;
• • This also meant that undo state was broken, which could spoil prefab template operations;
• • This occurred only when destructor for EditorSequenceComponent: was called before the destructor of the linked EditorSequenceAgentComponent; note that order of entities / components destruction is randomized, - I believe this depends on randomly generated Entity Ids and Component Ids and hence their positions in hash-tables, - for example I have two seemingly same level prefabs, differing only in entity aliases and components, which are randomly generated, and one of these was misbehaving;
• • So, in randomized destruction order this also broke the prefab loading / saving pipeline due to the EditorSequenceComponent::RemoveEntityToAnimate() was called second time from undo chain and thus was calling the EditorSequenceAgentComponent::DisconnectSequence() second time .
• • The first variant of a fix was removing the CAnimAzEntityNode containing the removedEntityId after calling the RemoveEntityToAnimate() from the EditorSequenceComponent destructor, and thus disconnecting this sequence component with that removedEntityId entity and destroying the EditorSequenceAgentComponent , yet this could introduce misbehaviour in the governing code which neglects calling AddEntityToAnimate() / RemoveEntityToAnimate()
• • The final fix is in temporary suppressing undo / redo during the EditorSequenceAgentComponent destruction in the EditorSequenceAgentComponent::DisconnectSequence(), as it this component is constructed not through the normal pipeline (designed for direct user actions evaluation). In order to temporary suppress undo / redo for this specific operation the commit 191e5cf :
• • • adds the new API to maintain "ignored entities list",
• • • adds checking this list when attempting to add dirty entities,
• • • and then uses this new API bracketing the the 'normal' codepath for the EditorSequenceAgentComponent destruction in the EditorSequenceAgentComponent::DisconnectSequence().

--

• Also fixes the crash on invalid pointer in CAnimSequence::RemoveNode() moving node destruction down below the node pointer usage.
• • Prior to this fix, calling the CAnimSequence::RemoveNode(IAnimNode* node) code first destructed the object erasing a vector element with the intrusive_ptr<IAnimNode>, and then attempted to use the now invalid node pointer;
• • The commit a991923 also adds a "TODO" comment to the identical code implementation of the CUiAnimSequence::RemoveNode(), changing and testing of which is out of scope for the current WIP.
• • This method was used in the previous version of the fix described above now used in a fix described below;
    --

How was this PR tested?

Repro steps of the issue #11500 with the Camera2 and the Seq entities repeated (numerously) under Windows:
a TestLevel with a Camera2 and a Seq entities containing (correctly linked EditorSequenceAgentComponent and EditorSequenceComponent respectively), - are now correctly saved an loaded.
Detached sequence entities were never noted in this scenario.

What is not done yet?

• When instantiating a prefab which was previously (with earlier code versions) saved with a spoiled (empty) "Parent Entity" sentence in the TransformComponent of a sequence entity, such prefab is still loaded wrongly;
  I believe fixing this would be helpful, as in most practical cases the AssetBuilder will rebuild a buggy prefab into a correct spawnable - see PR Track View: Optional fix for GHI #11500: fix prefabs previously stored with invalid entity parents. #18548.
• The problem also noted with incorrect structure of an in-memory template for a prefab recently created from a pair of Camera2 and a Seq entities in a level:
• • If the newly created prefab is deleted from the level, and then re-instantiated, it is instantiated with the "torn-off" Seq entity, because the cached in-memory DOM template is used, and this one is somehow asynchronously spoiled (the Seq entity forgets the correct container entity alias in the "Parent Entity" statement).
• • If a level is saved / reloaded or another level is loaded (thus releasing cached in-memory templates), the newly created prefab is instantiated correctly.