(v1.0) Use WeakMap for internal branding and dispatching

Using WeakMap to connect promises with their corresponding handlers
provides a much stronger “brand” for promises created by a particular
instance of Q.  Previously, we used the `promiseDispatch` duck type to
distinguish Q promises from other kinds of promise in the wild, but were
unable to distinguish a promise from another instance of Q, even from a
different version of Q.  This led to subtle bugs, especially when we
changed the promise interface to include `inspect`.

This introduces WeakMap and cribs small but insightful parts from Mark
Miller’s `makeQ`.

However, these changes cause various specs to fail, mostly pertaining to
the order in which progress notifications are dispatched.

The code for managing progress notifications, in its current state, is
worrying.  It appears that it was necessary to dispatch a "when" message
synchronously in the "then" method to attach promise handlers,
presumably so we would be able to listen for notifications in the same
turn the promise was constructed.  It seems that a symmetric change, to
dispatch notifications synchronously, solves the ordering problem.
However, synchronous registration and synchronous dispatch both
introduce plan interference hazards.  The consumer of a notification and
can interfere, and inspect the stack of, the producer of a progress
notification.

My intuition is that the specs are wrong and that we will need to relax
our guarantees about whether and when a progress notification will be
received.  As such, this needs further review.