Reuse current loop with execute

[trowski]

In the spirit of @davidwdan's PR #142, this PR allows the creation of loop events outside an execute context, however it still allows stacking of event loops and provides for consistent testing environments. The model here is inspired by @WyriHaximus's comment, allowing for both the React-style and Amp-style of creating events in the event loop.

With these changes both of the models below work as expected.

// React-style
Loop::defer(function () {
    echo '1' . PHP_EOL;
});

Loop::delay(1000, function () {
    echo '2' . PHP_EOL;
});

Loop::delay(2000, function () {
    echo '3' . PHP_EOL;
});

Loop::execute();

// Amp-style
Loop::execute(function () {
    Loop::defer(function () {
        echo '1' . PHP_EOL;
    });

    Loop::delay(1000, function () {
        echo '2' . PHP_EOL;
    });

    Loop::delay(2000, function () {
        echo '3' . PHP_EOL;
    });
});

Both will output:

1
2
3

Summary of Changes

• Loop::execute() now runs the currently active loop driver when invoked, allowing events to be created outside a running event loop.
• The callback to Loop::execute() is now optional.
• Loop::resetDriver() allows the active loop driver instance to be nulled if a loop is not running, allowing tests to easily reset the environment.
• If no active driver instance exists when Loop::execute() is invoked, the driver instance will automatically be set to null when Loop::execute() returns. If an active driver instance exists when Loop::execute() is invoked, that instance will remain as the active driver after Loop::execute() returns. This behavior preserves the state of Loop before and after Loop::execute() is invoked.
• Loop::createDriver() is now public to allow usage as the second parameter to Loop::execute().
• Stacked calls to Loop::execute() reuse the same active driver unless an a new instance is provided as the second parameter.
• Setting the loop factory with Loop::setFactory() does not reset the active driver instance.

[kelunik]

I don't think changing the behavior depending on whether an event has been created before Loop::execute or not is a good idea.

[trowski]

@kelunik The current behavior preserves the state of Loop before Loop::execute() is invoked (updated changes summary to make this clear). However, I considered leaving the driver that was created as the active driver after Loop::execute() returns. I'd like to hear more feedback on this point.

[trowski]

Closing in favor of @bwoebi's proposal in this comment.