DOM: Make selection test fail accurately

A selection preservation test for the `moveBefore()` API was added in
https://crrev.com/c/5725934 which passes falsely / incorrectly.
Selection preservation has not been fully implemented in Chromium, but
this test passes for two reasons:

  1. Inside the old parent from which the moved element is moved, there
     is no text except for the moved text. This appears to have a weird
     side-effect — if we `moveBefore()` from a parent that is otherwise
     empty, the selection returned by the `getSelection()` API appears
     to have the `anchorNode` still set to the new freshly-moved node.
     On the contrary, if you move text from a parent that has plenty of
     other preceding text, the selection returned from `getSelection()`
     *after* the move sticks to the preceding text, and indicates that
     the selection API does not preserve properly across moves.
  2. Before the `moveBefore()` API is called,
     `getSelection().anchorNode` is called. This *ALSO* has a weird
     side-effect of computing the `DocumentCachedRange()`, and since
     we have implemented the behavior to *NOT* update Ranges during an
     atomic move (in https://crrev.com/c/5725934), the cached range
     from before `moveBefore()` persists and deceptively indicates that
     selection has been preserved, when it hasn't been. Specifically,
     the cache range was indeed "preserved" by virtue of not being
     modified during the move, but in reality the *visual* (highlighted)
     selection was not preserved, and becomes out-of-sync with the
     cached Range selection returned by the selection API. By *NOT*
     calling `getSelection()` before the move, we ensure that we do not
     generate a cached selection Range, and by *only* calling
     `getSelection()` *after* the move, we force the Selection API to
     generate a cached selection Range based off of the actual visual
     selection, which gives us a truer picture of what the visual
     selection (the stuff that the user sees) *actually* is.

The test that this CL modifies accidentally relied on these two quirks
above, which made the test pass even though true selection preservation
was not implemented. This CL updates the test to not lean on these
quirks, so that it fails appropriately. A subsequent CL will implement
*visual* selection preservation properly, ensuring that the Selection
API's cached selection Range can never get out of sync with the visual
selection. That CL will add more tests and mark this one as passing.

R=nrosenthal@chromium.org

Bug: 40150299
Change-Id: Ifba24444f0c067643df650c69fb631fd94273d47
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5966878
Commit-Queue: Dominic Farolino <dom@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1374916}