Library hooks

[domenic]

Like #2, but the hooks are put on the libraries themselves (e.g. Q.onUnhandledRejection = ... or Q.on("unhandledRejection", ...)).

This has the con of making it hard to write generic debugging tools, but the pro of not co-opting some environment feature (like console or the global object) for nefarious purposes.

[briancavalier]

I much prefer the environment hooks of #2, but this would be a decent fallback if promise impls agree on naming for a core set of hooks to make it easier on debugging tools to be configured, or to discover them automagically.

FWIW, I don't really consider "providing a helpful debugging experience" to be nefarious :)

[ForbesLindesay]

There would need to be a consistent method of discovering those libraries as well though.