[cssom-view] extend scrollIntoViewOptions' *ScrollLogicalPosition* with `"farthest"` and `"none"`

Start with the linked CSSOM View specification section defining ScrollLogicalPosition and review the existing scrollIntoViewOptions block and inline values. Compare the proposed "farthest" and "none" behavior with the slider scenarios described in the issue; done requires agreed specification semantics for both new values.

Relevant spec: https://w3c.github.io/csswg-drafts/cssom-view/#enumdef-scrolllogicalposition

While Element.scrollIntoView() got a lot more practical with the current ScrollLogicalPosition block and inline values, there is still some scenarios that would benefit from additional options that are "farthest" and "none".

In both cases, the scenario is that we've created a scroll slider whose items are at such a narrow size, that you would see e.g. three of them at once with the fourth being cut off at the border.

The slider has arrow key support as well as programmatic scroll buttons on both sides. We use IntersectionObserver to keep track of the visibility of each item in the slider, so that we can determine which item to scroll into view when the user strikes an arrow key or clicks one of the two directional scroll buttons:

• arrow key / button click towards end: last item from the start with < 1.0 intersection
• arrow key / first item with < 1.0 intersection after a series of items with 1.0 intersection

CodePen example: https://codepen.io/Schepp/pen/KKeyaJx

Now to how "farthest" and "none" ScrollLogicalPosition can help us here:

• "farthest": when a user triggers a scroll further towards one direction, what we want is to grab the first not / not fully visible item in that direction and to scroll it not just slightly into view, but all the way up to the opposite end of the visible area, thereby unveiling a lot more items behind it. The only way to realize this at the moment is to swap between inline: "start" and inline: "end" depending on the direction chosen by the user. While this is not that hard to do, the code could be simplified with an inline: "farthest" - also given that there is the option "nearest".

• "none": depending on the screen size and the scroll position the slider might be cut off somewhere in block direction. Now when a user triggers a programmatic scroll, either by striking an arrow key or clicking a scroll button, what happens is that not only does the inner part of the slider scroll in the inline direction, the whole slider itself will also scroll into view in block direction, if cut off. This is a bit irritating. It gets downward bad UX the moment it is wired to autoforward using that same programmatic code as every time it scrolls, it will pull the viewport to show it again. I currently stop that to happen by observing the slider itself via IntersectionObserver and pausing autoforward once it gets cut off. An ideal solution for this would be to extend ScrollLogicalPosition with a "none" option, so that we can set block: "none" and be good.