Improve memory consumption by only passing resolver args to resolver and canceller if callback requires them

[clue]

While debugging some very odd memory issues in a live application, I noticed that this component shows some unexpected memory consumption and memory would not immediately be freed as expected when a pending promise is cancelled. Let's not call this a "memory leak", because memory was eventually freed, but this clearly caused some unexpected and significant memory growth.

I've used the following script to demonstrate unreasonable memory growth:

<?php

use React\Promise\Promise;

require __DIR__ . '/vendor/autoload.php';

for ($i = 0; $i < 1000000; ++$i) {
    $time = time();
    $promise = new Promise(function () { }, function () use ($time) {
        throw new Exception();
    });
    $promise->cancel();
}

var_dump(memory_get_usage());
var_dump(gc_collect_cycles());

Initially this peaked somewhere around 15 MB on my system taking 3.4s. After applying this patch, this script reports a constant memory consumption of around 0.7 MB taking 1.8s

Empirical evidence suggests that many common use cases do not use the $reject (etc.) arguments and instead simply throw an Exception. The Promise class now uses reflection to check whether the $resolver and $canceller functions actually define any arguments and if they are not expected, doesn't actually pass them. This does involve some minor runtime overhead for using reflection, but this is actually compensated by not passing any closure arguments (1M invocations that do no use arguments show ~40% performance improvements, 1M invocations that do use arguments show a ~3% performance degradation).

More importantly, not passing these arguments has the side effect of these arguments not showing up in the call stack anymore. This is particularly important when throwing an Exception, as it would otherwise keep a reference to the promise instance in its call stack (while the promise stores the reference to this exception) and as such would cause a cyclic garbage reference.

Previously, these cyclic garbage references were eventually freed by the cyclic garbage collector after accumulating around 10000 entries with somewhere between 8MB to 15 MB. These can now be freed immediately and thus no longer cause any unexpected memory growth. This implementation includes some of the ideas discussed in reactphp/promise-timer#32, #46 and reactphp/socket#113.

Note that this PR does not resolve all unexpected memory issues. However, it addresses a very common problem for many consumers of this library and makes many of the higher level work-arounds obsolete. My vote would to be get this in here now as it addresses a relevant memory issue and eventually address any additional issues on top of this.

[kelunik]

The reason for it being faster isn't avoiding the arguments being passed, but rather the three closure creations that are saved.

[clue]

@kelunik Do you feel that this helps with understanding the motivation for this change? If so, I encourage you to file this as a new documentation PR and maybe back this with some numbers

[kelunik]

@clue I think the motivation is completely covered by the circular references, the rest is just additional background on the performance of the patch. It's not super important to change, just a minor note I had while reading.