Allow to delay going to pending state on refetch

[LFDM]

Whenever incoming props change and the component needs to refetch, we would go to pending state. If all data that needed resolution was available immediately (immediately means: promises which resolve immediately), this lead to the following situation:

• We go to pending state, the view component is unmounted
• We never see the pending component, because React doesn't flush these updates to the DOM so quickly - they defer their updates as well.
• We immediately unmount the pending component and mount the view component again.

We can now opt-into a waiting time to defer going to the pending state altogether.
At the point of a refetch we do have data to display already - so instead of going to pending, we just opt-in to show the old data a little longer, before displaying a pending component (or the next view state, in case the data arrives inside of the specified delay window).
This is opt-in for now - there might be cases where mounting and unmounting are exactly what you want, so there will always be a way out of this (e.g. for some sort of animation), but a feature version might default to do skip this pending state for a tiny bit.

An interesting change in this aspect is this 5c26407. Without this commit the view component would still have rerendered immediately with the new props incoming. It would have received new components passed down from the outside, but still gotten the old data.
This commit prevents this - as long as the delay is in effect, the view component will not know anything about a prop change.
IMO it needs to be this way - because up until now the inner component was guaranteed to receive all incoming props as well as the resolved data withData provides. We should not break this contract, as a mismatch of incoming and resolved props could potentially lead to bugs.

The feature is fully working

Ideally this could be solved without timeouts, but i think it just can't. Currently setting the timeout length to 0 will also skip the delay - this is something which could change imo.

Will open a second PR in a bit, which builds up on this and deals with a minimumPendingTime - which is not 100% there yet.