Custom builds: use different ready code when excluding Deferred

[timmywil]

• Modules depending on deferred are excluded when deferred is excluded (ajax, effects, queue, and core/ready). Whenever deferred is excluded, core/ready is replaced by core/ready-no-deferred.
• jQuery.ready.promise has been removed and jQuery.ready made a thenable in core/ready.
• When an error thrown from ready handler all subsequent handlers are not being invoked #1823 (error resiliency) has been addressed by giving up our synchronicity guarantee in ready handler execution after the ready event has been fired. This has multiple advantages. Besides error resiliency, it makes use of our standards-compatible .then in the .ready method.

[mention-bot]

By analyzing the blame information on this pull request, we identified @markelog, @mgol and @mikesherov to be potential reviewers

[gibson042]

I'm pretty sure you can get rid of readyPromise and just use readyList directly.

[gibson042]

Do we want to keep the document context? It's another backwards-compatible but non-Promise "feature". And if we do keep it, there should be verifying assertions in test/unit/ready.js.

[timmywil]

Perhaps we can leave that subject to change/undocumented. I don't want to verify it if we're going to change it in a future version.

[gibson042]

I'm suggesting that we change it now, in both places.

[timmywil]

Let's open another ticket then. This PR is already 2 tickets. I'd rather not hold it up. But I'm indifferent as to what context we use here. document still makes sense since it's the document ready handler.

[gibson042]

This PR is the introduction of jQuery.ready.then... why start off on the wrong foot when we don't have to? It doesn't even make sense to create a ticket referencing behavior that hasn't landed. But I guess I'll put some text here just in case:

Per Promises/A+ and ES2015, then callbacks should be called without a this context. And although jQuery.Deferred#*With methods provide context to callbacks, we are moving in the direction of increased standards compliance, and should stop providing document context to jQuery.ready callbacks while we're already making backwards-incompatible changes to jQuery.ready.

[dmethvin]

I'm fine with not passing document, we just need to document that and the fact that it's async now. I can do that in the release notes once this lands.

[timmywil]

@gibson042 The change wouldn't just affect jQuery.ready.then, and I'm familiar with the spec on Promises. Like you said, the document context is for back-compat, as we still have $(function(){}) and $(document).ready(), and while some may prefer Promise.resolve(jQuery.ready), I imagine that $(document).ready() and $(function() {}) will still be the most common, and a document context still makes sense to me on the latter 2. Like I said tho, I'm not opposed to changing that, but we don't have to change it now.

[gibson042]

Ok, I can accept that: gh-3026.