To fix cursor next / prev behaviour when they encountered prepared updates resulting from insert / update / remove operations.

Behaviorally, we went had a few iterations about what the expected state of a cursor should be after WT_PREPARE_CONFLICT is returned. We ended up choosing the following semantic:

Have the cursor remain on the item when prepare conflict is returned, but handle subsequent move operations correctly in all scenarios: aborted, committed and visible, committed and not visible, at the start and end of the tree.
For read-uncommitted transactions, the prepare conflict return needs to be considered as changing the position of the cursor - otherwise changing traversal direction after a prepare conflict can result in out of order cursor returns.