FLEX-34119 renaming variables for increased readability.
FLEX-34119 Adding two unit tests for HierarchicalCollectionViewCursor (HCVC). HierarchicalCollectionViewCursor_Basics_Test is meant to ensure that HCVC works as expected in non-corner cases (it's definitely incomplete, and could use more tests. I created it mainly to test the few functions I needed when working with FLEX-34119), while HierarchicalCollectionViewCursor_FLEX_34119_Test reproduces the FLEX-34119 bug (and, incidentally, also uncovered FLEX-34424). FYI The latter test lasts just under 3 minutes on my machine.
FLEX-34119
CAUSE:
HierarchicalCollectionViewCursor.collectionChangeHandler dealt with CollectionEventKind.ADD and CollectionEventKind.REMOVE events in a defective way: when the event happened before the currently-selected node, but in a different collection from the selected node, it assumed that it could use the currentChildBookmark to correct the position of the bookmark in that collection. However, currentChildBookmark can only be used on the collection it was created in, which is the collection of the currently-selected node and its siblings. This made ListCollectionView.getBookmarkIndex throw the 'Bookmark no longer valid' error.

SOLUTION:
In the case detailed above instead of changing the currentChildBookmark we need to adjust the bookmark associated with the collection that the changing (i.e. added or removed) node is in.

NOTES:
-Another problem in HierarchicalCollectionViewCursor.collectionChangeHandler was that currentChildBookmark was (attempted to be) updated with the corrected position of the parent of the changing node's sibling collection. However, currentChildBookmark represents the position of the currently-selected item, and should only be updated when the selected item's siblings collection changes, not when other collections change. Instead, we need to update the parentBookmarkStack collection, which contains the positions of the selected node's parents' positions in their collections.
-After these changes HierarchicalCollectionViewCursor_FLEX_34119_Test doesn't show any more 'Bookmark no longer valid' errors. (But it still fails due to FLEX-34424).
FLEX-34119 Adding some explanations on the main unit test.
FLEX-34119
Simplified two if statements, removed an unused variable, and removed Duplicate variable definition warnings in HierarchicalCollectionViewCursor.
FLEX-34119
Renamed a Boolean for clarity in HierarchicalCollectionViewCursor.collectionChangeHandler.
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.
FLEX-34456 Added a unit test which reproduces the bug.
Merge remote-tracking branch 'origin/develop' into FLEX-34119
FLEX-34456
CAUSE:
When a HierarchicalCollectionViewCursor reacted to a deletion before another cursor, it deleted the parent mappings of the deleted nodes (even if it didn't need to make any changes to its internal state). Since these mappings are on the HierarchicalCollectionView, the next cursor to react to the same deletion would compute that the parent of the deleted node is null, and everything went bad from there.
In other words, if two or more cursors are created on the same HierarchicalCollectionView, they will work against each other when deletions occur (or replacements, which HierarchicalCollectionView transforms into deletions).
I think that the mapping deletions happened because HierarchicalCollectionViewCursor was written with the assumption that there would only be one cursor for each collection.

SOLUTION:
Now we're making it HierarchicalCollectionView's job to remove the parent mappings of all the affected nodes after it gives all the cursors the chance to react to the deletion.

NOTES:
-As part of this change I realised that the conditions for an if clause introduced for FLEX-34424 were not enough: in order to choose strategy 2) (see revision 82d6b51 for details) for adjusting the cursor position, not only does current need to be null, but afterLast and beforeFirst need to be false (because if they are true, it's expected and correct that current == null).
-This led me to notice that HierarchicalCollectionViewCursor.beforeFirst was true if current == null && currentIndex <= collection.length, which doesn't make sense. In fact, these conditions correctly determine the FLEX-34424 situation, in which the item at the current index doesn't exist anymore, which makes current null, although currentIndex is within bounds. (Another clue that the condition for beforeFirst is wrong is ListCollectionView.beforeFirst, which checks the index against -1, rather than allowing any index up to the collection length.) So I changed this to check for any value < 0.
-I also made HierarchicalCollectionView.parentMap private instead of accessible from other classes (like HierarchicalCollectionViewCursor), and made the operations on it (deletions and additions) accessible only through functions, rather than using the map directly, as before.
-Both the above changes also affected LeafNodeCursor, which also had a defective beforeFirst getter, and also directly manipulated the collection's parentMap.
-Also removed unused variables from HierarchicalCollectionView.removeChild() and .collectionChangeHandler().
FLEX-34458 Added a unit test which reproduces the bug (which means it currently fails).
FLEX-34458
CAUSE:
Because HierarchicalCollectionViewCursor uses both relative and absolute bookmarks in the various collections of the hierarchy, there needs to be special treatment for these two cases. Namely, while it works great with absolute bookmarks to call .movePrevious on the bookmark when something is deleted in the same collection before the selected item, it doesn't work well for the relative CursorBookmark.LAST currentChildBookmark value. Because HierarchicalCollectionViewCursor.collectionChangeHandler() did not make any difference between absolute and relative bookmarks, it used to call .movePrevious() on the bookmark even if it was the absolute value CursorBookmark.LAST.

SOLUTION:
In this situation we don't need to .movePrevious() when items above are deleted, because CursorBookmark.LAST will always point to the last item in the collection, no matter what changes happened to that collection.