Recommendation for when add/queue steps should run

[igrigorik]

Closes #55.

@yoavweiss @toddreifsteck @plehegar ptal.

[toddreifsteck]

Not a fan. Please refer to #55 comments. Happy to discuss on 11/17 call.

[igrigorik]

(Rough) summary from our call last week...

• Ideally, we should have a MUST: that allows us to write clean interop tests, avoids surprises for developers, and so on.
• Currently, the spec leaves this behavior undefined and browser implementations differ + sometimes vary based on type pf resource. That is, sometimes you can count on the entry being queued before load event is fired, but sometimes that's also not the case in the same browser; different browsers have different permutations of this behavior. As such, in practice, what you can count on is that the entry will be available sometime after the resource has loaded + been processed.
• Moving forward, we are encouraging developers to use PerformanceObserver, which actually has very similar semantics as above: it does not make any guarantees about when the even is delivered, and the processing algorithm specifies that such events should be queued from a low priority queue to minimize contention with other (more critical) browser work.
• If we change the behavior to a MUST and current implementations update.. Will they break existing code that relies on events being available at a particular point in time? This is very plausible, but there is high likelihood this code already doesn't work in some browsers, and it will not work in any new implementations after the spec update is made -- e.g. Safari, if/when they ship RT2.

As next steps, we identified...

• @toddreifsteck to check with his team on queueing after ~load event
• ...?

@yoavweiss @toddreifsteck what other questions do we need to answer to resolve this?

[igrigorik]

As per discussion on the call today.. Opened #82 and updated this PR to link to it. Merging.