Promise implementation as a option

[hnry]

Would like to be able to pass our own Promise implementation as an option over setting it as global.

Reasoning:

• libraries using this library are forced to have to implement the same strategy and disclaimer to a user, as we shouldn't touch a user's global. But we may want to just support only Promises, as we can provide our implementation (but there's no way to do that without being able to pass it in as an options).
• there exists a wide variety of different Promise libraries and implementation. The one that exists on global may not be the implementation a user or library writer wants to use and touching global may not be an option a user wants to do, and definitely not what a library writer using this lib wants to do

[Douglas Wilson]

I really don't want to change this, sorry. There has been this same conversation on various repositories I manage and from all that discussion, I can sum it up as follows:

1. Code using a library should not be dependent on what Promise library it uses; all that matters is that it is Promises/A+ compatible.
2. A consumer that wants to use "sugar" promise methods should wrap another module's promise in that sugar one. Promise/A+ modules provide the Promise.resolve static method for this exact purpose. Example: YourPromise.resolve(getRawBody(stream)).then(...)

I hope this helps! From a lot of the prior discussions, it seems the most common misconception is that a library needs to be able to take a custom Promise constructor to use promises. Rather, the global Promise is supposed to be an intrinsic part of the language; you don't see people going around asking for library to take a custom Date, Array, etc. constructor, just like they should not be doing with Promise. Using Promise.resolve is the correct method to use your own promise flavor with any module.