Add :upward support

[AdamWr]

In uBlock Origin :upward() will be a synonim for :nth-ancestor, so I think it would be a good idea to supports it too.

More details - gorhill/uBlock@72bb700

[slavaleleka]

Although "upward" is based directly on Xpath, I've found that number-based "upward" entries can be converted into pre-existing AdGuard/ABP syntax with ease.
E.g. example.org##.element:upward(2) → example.org#?#*:-abp-has(> * > .element)

[AdamWr]

Positive number >= 1 and < 256, distance from the currently selected node.

If I understand correctly, rule like this:
example.org#?#a:upward(0)
or this:
example.org#?#a:upward(256)
should be treated as invalid, but it seems that currently the first one (example.org#?#a:upward(0)) works the same as:
example.org#?#a:upward(1)

Link - http://example.org/

[AdamWr]

Limited to work properly only at the end of selector, except of pseudo-class :remove().

What is the reason of this limitation?
I mean that in third party filters there are few rules like this #?#selector:upward(1) + anotherSelector, so these rules will not work.

For example in Swedish filter:

tidningen.nu##span:has-text(/^Annons$/):upward(1) + .textwidget
viafree.se##.vjs-playing:upward(1) ~ .no-autoplay-overlay

https://github.com/AdguardTeam/FiltersRegistry/blob/6cce7c92672856220f256e85a26a2494196e35c3/filters/ThirdParty/filter_243_FrellwitSwedish/diff.txt#L200

[ameshkov]

@slavaleleka the question makes perfect sense, what's the reason for this limitation?

[ameshkov]

Actually, this won't be easy to handle at least until we ditch Sizzle. Let's live with this limitation for now.