Optimize the preload mechanism on desktop and mobile about preload-plugin

[hirasso]

We decided that starting preloads on touchstart is an easy gain. Implemented in #53 .

Updated planned logic on desktop:

Anytime a link is hovered:

1. If there is already a preload running that was initialized by a hovered link, abort it
2. Start a new preload for the currently hovered link
3. Don't abort preload requests that where initialized directly (initial page preload or preloads initialized by preloadPages)

This will make sure that the link a visitor actually wants to visit won't be blocked by a previously hover-initialized and not yet finished preload.

Planned API:

// will be aborted by a subsequent preloadPage request
preloadPage(url, { priority: 'low' });
// won't be aborted:
preloadPage(url, { priority: 'high' });

A lot of this was already implemented in #46, but we decided to wait with this until swup@3 is released. That way we won't have to re-implement the abort logic once we have made the switch to the fetch API, as proposed by in swup/swup#566