FLEX-34119 FLEX-34440 Adding the setItemAt() operation to HierarchicalCollectionViewCursor_FLEX_34119_Test, which uncovers FLEX-34440. Separate unit test for FLEX-34440 will follow.
FLEX-34440 Added unit test to reproduce FLEX-34440. This also required a few changes in HierarchicalCollectionViewTestUtils.
FLEX-34119 FLEX-34440 changing the package of the unit tests (and helper classes) to mx.collections.
FLEX-34119 FLEX-34440 Renaming variables to make code more readable.
FLEX-34440
CAUSE:
When HierarchicalCollectionView converts a CollectionEventKind.REPLACE CollectionEvent into a CollectionEventKind.REMOVE one, it also deletes the parent(s) of the replaced node root(s). However, if the HierarchicalCollectionViewCursor which then immediately responds to this converted event (in collectionChangeHandler()) happens to have its 'current' node inside the replaced branch, it will fail to retrieve all the parents of the current node, because the parent of the root of the branch has been deleted. This is problematic, because HierarchicalCollectionViewCursor.collectionChangeHandler assumes that parentStack and parentBookmarkStack have the same number of items, and that any item in the latter array represents the position (CursorBookmark) of an item in the former array in its siblings collection. So it will try to use a parentBookmarkStack item on a different collection to which it was created on, thus throwing a 'Bookmark no longer valid' CollectionViewError.

SOLUTION:
HierarchicalCollectionView.nestedCollectionChangeHandler now deletes the parent(s) of the replaced node root(s) *after* dispatching the converted CollectionEvent, as opposed to *before*.

NOTES:
-This now makes HierarchicalCollectionViewCursor_FLEX_34440_Test pass.
-Also removed three unused local variables from HierarchicalCollectionView.nestedCollectionChangeHandler.
FLEX-34424 Added a unit test to reproduce FLEX-34424. As expected, it is currently failing.
Also added a few more tests to HierarchicalCollectionViewCursor_Basics_Test to do with the deletion of nodes. These are currently passing.
FLEX-34424 Improved the unit test by making it parameterized and adding a few more cases.
FLEX-34424
CAUSE:
HierarchicalCollectionViewCursor deals with deletions of nodes before the current node in two distinct ways: 1) relatively: if it's possible, it calls movePrevious() as many times as the number of nodes removed; if not, 2) absolutely: it seeks to the location of the first deleted node from the beginning of the hierarchy.
The problem was in the conditions used to determine whether to use method 1) or 2): indeed, method 1) should be used when the node that used to be at 'currentIndex' has been directly affected by the deletion (i.e. that node is among the ones deleted). However, it should also be used when it has been indirectly (but irretrievably) affected, because enough nodes have been removed from its siblings collection that there is no item anymore on the value of the CursorBookmark we have stored for it (i.e. if it was the 8th node in a collection of 9 nodes, and two nodes before it have been deleted, there's no 8th node to retrieve anymore). The way we know this is that HierarchicalCollectionViewCursor.current now returns null.
(So when 'current' was null, it was impossible to retrieve the parent stack of the items up to the root, and everything would fail from there onward.)

SOLUTION:
Choose deletion strategy 1) when 'current == null'.

NOTES:
-This now makes HierarchicalCollectionViewCursor_FLEX_34424_Test pass.
-This implies that the computation of the parent nodes (in the 'parentStack' array) now happens after this check, whereas it used to happen before.
-It also implies that the index HierarchicalCollectionViewCursor seeks to in strategy 1) is different when 'current == null' (namely, it's 'currentIndex - n').
-Renamed some variables in these conditional statements, to make it easier to decypher what is happening.