Evaluate changing Mark Paint Timing to flushPaintTimings actually at paint time.

[mmocny]

(Context: WICG/soft-navigations#65)

Today the mark paint timing steps will observe paint, compute a set of new painted images and text nodes, and finally create a flushPaintTimings callback.

Invoking that flushPaintTimings is needed for actual paint apis to "observe" paint steps.

But according to steps 11 and 12, on implementations that support presentation time, the actually flush happens "in parallel" after presentation time is known.

This causes some issues whenever PerformanceEntry creation requires reading some global state, which can change between paint steps and eventual presentation time processing.

For example:

• Capturing the element's id, depends on element still being attached to DOM and the id attribute not changing
• navigatonId is assigned when a PerformanceEntry is queued, and can change between paint and presentation time processing.

[noamr]

Probably some of this state needs to be read at mark time rather than at flush time?

[mmocny]

Exactly right-- but the APIs don't have a way to observe paint with the current integration. For navigationID only I could just make paint timing do this, but I thought it would be better to "create" all PerformanceEntry aligned with paint time, on all browsers, and then presentationTime is just assigned afterwards/

Something like "queue PerformanceEntry with PaintTiming".