Expose time from the hardware timestamp to startTime

[yoavweiss]

At #14 we decided that the best startTime timestamp is at the processing end, as it toughly matches (even if not precisely) what other navigations are doing on the platform.

But, talking to @noamr, he made the argument that it'd be good to have a less ambigous timestamp that would enable various future comparisons - the hardward timestamp.

So, we talked about exposing an interactionToStartTime measurement, that would represent the duration between the hardware timestamp and startTime. It may be interesting to also expose the same as part of NavigationTiming.

^^ @mmocny @iclelland

[mmocny]

Makes sense to me.

LoAF has a similar idea in its "firstUIEventTimestamp".

In a perfect world, we would directly link to an Event Timing entry and/or interactionID, but you can use event.timeStamp and event.type to == on EventTiming.startTime and EventTiming.name -- and then you don't have to wait for presentation time (LoAF has the same issue)