Initial prototype for AbortablePromise

**DO NOT MERGE**: This is a prototype of an AbortablePromise, for discussion and iteration to prove the idea.

This adds a new AbortablePromise subtype that has an `abort()` method which can send a signal from a consumer back toward the root of the promise graph to the producer indicating that the consumer wishes to abort the task that is computing the promise's value.  This can be used to stop long-running or resource-consuming tasks when a consumer decides it no longer wants the result.  For example: XHR request.

#### Initial prototype

The initial implementation isn't ideal but is headed in the right direction.  The abort functionality should be provided at the handler level, and a thin wrapper for it provided at the AbortablePromise.prototype level.  The initial prototype does that, but by stashing an additional property on the existing handler.  Ideally, we would have a new type of handler, eg AbortableHandler, that provided the functionality.

#### Open questions

This prototype doesn't provide `AbortablePromise.resolve` or `AbortablePromise.reject`.  I believe that it will need to.  The reason is for API consistency: APIs that return `AbortablePromise` may need to return resolved and/or rejected promises, and returning `Promise.resolve/reject` would return a promise without an `abort()` method, which would break callers of those APIs.

`Promise.all` and `Promise.race` may also need abortable analogs that return an `AbortablePromise`.  They would also need to handle abortable *thenables* in their input arrays, aborting them when the returned promise is aborted.  That may be a slippery slope into needing to detect `abort` in many more places (when.map, when.filter, when.reduce, etc etc etc).

cc @mjackson
Instead of returning `undefined` here, should we return a promise for the previous `abortResult`?