Fixing `Promise.resolve()`

[C. Scott Ananian]

Hopefully everyone has had a little bit of time to think over the
issues with Promise.resolve().

Last week I proposed three different reasonable semantics for
`Promise.resolve`, none of which involve the `[[PromiseConstructor]]`
internal field:
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50

I continue to feel that the "no species" proposal is the best
alternative, reasoning that `Promise.resolve` is more like an explicit
constructor than an species-using instance-transformation method.
Here's that proposal again:

> Promise.resolve(x)
> 1. Let C be the this value.
> 2. If IsPromise(x) is true,
>      a. Let constructor be the value of Get(x, "constructor").
>      b. ReturnIfAbrupt(constructor)
>      c. If SameValue(constructor, C) is true, return x.
> 3. Let promiseCapability be NewPromiseCapability(C).
> 4. ReturnIfAbrupt(promiseCapability).
> 5. Let resolveResult be Call(promiseCapability.[[Resolve]], undefined, «x»).
> 6. ReturnIfAbrupt(resolveResult).
> 7. Return promiseCapability.[[Promise]].

All mentions of [[PromiseConstructor]] should then be
garbage-collected from the spec.

This simplifies the semantics and fixes the "hidden new.target"
brokenness which affects interoperability with code written in ES5
syntax.  Eliminating "species" here also yields more useful behavior
from `P.resolve` if an subclass sets `P[Symbol.species] !== P`.

It's my understanding that Mark Miller volunteered to champion the
changes to `Promise.resolve` at the next TC39 meeting.  (Thanks,
Mark!).

I'll update `es6-shim` and `core-js`/`babel` if/when TC39 reaches
consensus on this.

Thanks!
 --scott