Documentation for timer API and clean up unneeded timer API

[clue]

The timer API is currently entirely undocumented and offers several duplicate methods and accessors not really required. Arguably, this makes the timer API appear more difficult than it actually is. The loop accessors also causes an unneeded cyclic dependency which hinders garbage collection.

This PR adds documentation for the existing timer API and then subsequently removes unneeded methods and the cyclic dependency. Note that while this PR does remove parts of the existing API, it does not add any new APIs or otherwise modify the existing APIs. While this does contain some BC breaks, many consumers will not be affected by this due to the duplicate methods. This PR ensures to provide some upgrade guides to those affected by the BC breaks.

Performance improvement is not a major motivation here, but shows a negligible 3-5% improvement anyway (running examples 92 and 94).

If you want to review, consider also looking at the individual commits.

Builds on top of #99 and #100.

cancelTimer() and isTimerActive()

// old (methods invoked on timer instance)
$timer->cancel();
assert(!$timer->isActive());

// already supported before: invoke methods on loop instance
$loop->cancelTimer($timer);
assert(!$loop->isTimerActive($timer));

Use closure binding to add arbitrary data to timer

// old (limited setData() and getData() only allows single variable)
$name = 'Tester';
$timer = $loop->addTimer(1.0, function ($timer) {
    echo 'Hello ' . $timer->getData() . PHP_EOL;
});
$timer->setData($name);

// already supported before: closure binding allows any number of variables
$name = 'Tester';
$loop->addTimer(1.0, function () use ($name) {
    echo 'Hello ' . $name . PHP_EOL;
});

Remove getLoop() and suggest using closure binding instead

// old (getLoop() called on timer instance)
$loop->addTimer(0.1, function ($timer) {
    $timer->getLoop()->addTimer(0.1, function () {
        echo 'Hello';
    });
});

// already supported before: use closure binding as usual
$loop->addTimer(0.1, function () use ($loop) {
    $loop->addTimer(0.1, function () {
        echo 'Hello';
    });
});

[nrk]

These changes definitely make sense at this stage of ReactPHP. The current API defined by React\EventLoop\TimerInterface was motivated by an hypothetical transition to a full object-based approach that wrapped resources managed by the event loop, but this vision never really took shape for various reasons (even practical ones). Probably this was never discussed in the public or maybe just on IRC, this is something that happened at the very early stages of the project after all.