Different versions of Qt (or maybe it's the position of Jupiter-vs-
Saturn) seem to behave differently with regard to whether delegates
in a Repeater+Flow package initially appear at 0,0 and then get moved
into position, or directly appear at target geometry. This is despite
the fact that we already layout before changing delegate visibility
to true.

The former behavior causes various problems. One of them is that after
clicking a launcher, a new task delegate can be under the mouse cursor
initially (even though it never shows up in a rendered frame - this
only matters for event checks) causing containsMouse to be true and
then never to go false as the item is moved from under the cursor
(which Qt Quick's hover handling famously can't handle). Another is
that we export delegate geometry in global coordinates to kwin so it
knows where to animate window minimization to, and this needs to be
the correct (i.e. 'final-initial') geometry.

Previously, we tried to handle this by only enabling hover event
handling and doing the initial geometry export on two triggers:

• onVisibleChanged(true) && index == 0 + boolean fence=false
• onXChanged + boolean fence=false

This worked, but breaks the case where an item actually appears at
the desired final-initial geometry directly, so not causing an
onXChanged.

After brainstorming we couldn't come up with a better alternative
than a trigger. Exploiting Flow's add transition seems to error-
prone given various gotchas mentioned in the docs, and delaying
things by one event loop iteration is too brittle, since we don't
know exactly how this interacts with scene graph positioning.

So this changes things to a singleshot timer, which is created and
started whenever a task is completed or changes its type to window
(the latter for the geo export). The duration matches what the
Flow move animation is set to (now ported to units) to make sure
it can't interfere.