refactor the Promises$reduce state machine

I experienced failures while attempting to use `Promise.reduce` under a variety of conditions, many of which involved staggered asynchronous resolution of
- the accumulator / "initialValue"
- the "0th value", when no "initialValue" was provided
- values in the Array to be reduced
- the reduce iterator

Significant attempts were made to patch the existing `Promise$reduce` implementation, but once a Test Suite considering a matrix of asynchronous permutations was implemented, I concluded that the existing code was un-patchable :(

The most pragmatic course of action was to refactor its state machine logic so that it could better separate the multiple phases of the reduction process

1. inbound flow of resolved values for the "initialValue" / "0th value" (Phase 1)
2. inbound flow of resolved values from the Array to be reduced (Phase 1)
3. inception of, and incremental reduction of, the Array values (Phase 2)
4. detecting completion

The previous implementation did all of these things, but a thorough Test Suite revealed that there was too tight of a coupling between the inbound flow and the incremental reduction processes. This became most evident when the values in the Array resolved at staggered intervals and the reduce iterator did so as well.

I understand that this is a *considerable rewrite* and I am eager to collaborate with you to bring it up-to-spec with your current module design via your code review process.

The Test Suite for `Promise$reduce` has grown significantly, and it is possible that some cases are redundant or unnecessary.  I wanted to be absolutely sure of the new code's stability, especially in the light of the multi-phase state machine and its edge conditions. I left the existing Test Cases in place, though they may now be redundant.

Thank you for all the work you've put into the library.  It is a shining beacon of the Promises specification.