FLEX-35043 PROBLEM: The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move made obvious another problem caused by FLEX-34885: calling itemUpdated(item) did not reposition the item according to the sorting rules (unless the Sort had a customCompareFunction). CAUSE: FLEX-34885 assumed that the initial logic of checking for !updateEntry.property was to detect when entire objects were replaced with others in the collection. However, it was also detecting when the developer signalled that something (undefined) about an object had changed, and they wanted the sorting / filtering to be reapplied.
SOLUTION: now we call moveItemInView() also when updateEntry.property is null and there are no oldValue or newValue specified in the CollectionEvent.
NOTES: -also updated ListCollectionView_PropertyChangeEvent_Tests and added a new function for objects which are not bindable. As expected, there is a failure without this change to ListCollectionView, and with the change all unit tests pass. -made explicit a conversion from Object into Boolean in a call to moveItemInView(). -reformated event instantiations to be on one line. -made some minor changes to SF_ORIG_ListBasic.mxml, which is used by SF_ORIG_list_events_tester.