Improve support for actions involving multiple navigables

[jgraham]

This makes the following changes:

• Actions are always dispatched first to the top-level traversable rather than directly to the target navigable. It is assumed that the action will end up interacting with the target traversable, but may not e.g. if there is an element obscuring the target, or the focus is in the wrong place.

• To support the above, coordinates are computed relative to the viewport of the top-level traversable rather than the target navigable.

• A new coordinate origin type is introduced which has the form: { type: "viewport", context: <context id> }

  This is designed to allow targeting inside a specific iframe without that iframe needing to be the target of the overall actions chain.

The existing behaviour that if the main target navigable is deleted the action chain is terminated remains. This makes the behaviour consistent between top-level traversables and iframes, and also between different actions.

---

Preview | Diff

[jgraham]

There are still a number of open questions here:

• The new coordinate origin is the first thing to introduce the idea of a global id for navigables (particularly iframes) into WebDriver classic. The design is a natural fit to BiDi, but there's a question about whether it's appropriate for Classic.
• Similarly the current element origin depends on the element being in the target navigable. In BiDi it's rather easy to add a context parameter to the element origin to specify where to look for the element, but that doesn't work for web elements. The alternative would be to allow searching the entire tree of navigables under the top-level traversable for the element. That would be easy to use, but might have perf implications.
• It's unclear that we're maintaining the current behaviour for elements that are inside the viewport of an iframe but outside the top-level viewport (e.g. consider a case where a button is inside an iframe, and would be visible if you scrolled the top level document, but where the entire iframe is currently entirely out of view).
• I worry a bit about how backwards incompatible the change is. I know it's similar to what Chrome is already doing, but I want to check that there aren't any features of the Chrome implementation that aren't captured here (e.g. implicitly moving focus to the target navigable at the start of the action chain). With wheel and pointer events the fact that they might be captured by the top-level document is considered a feature, but I'm not so sure about key events.