Feature request and implementation for NodeTraverser::removeVisitor

This pull request adds a test and implementation for removing an added `PHPParser_NodeVisitor` to a `PHPParser_NodeTraverser`. You pass a `NodeVisitor` as the first argument to the method and any added visitors strictly (`===`) matching that object will be removed. A side effect of this is that the visitors array's indices may become unordered but this doesn't appear to be a problem as I didn't see anyplace where you were relying on that.

I realize this alters an interface and might not be quickly merged in but I think it provides some useful functionality and allows better control over what visitors a traverser will wind up invoking.

---

## Use Case

Running static analysis on function use in a set of files.

```php
<?php

class AnalysisVisitor extends PHPParser_NodeAbstract {

    private $nodes = [];

    public function enterNode(PHPParser_Node $node) {
        // do your check to store $node in $this->nodes
    }

    public function getNodes() {
        return $this->nodes;
    }

}

class Analyzer {

    private $parser;
    private $traverser;

    public function __construct(PHPParser_Parser $parser, PHPParser_NodeTraverserInterface $traverser) {
        $this->parser = $parser;
        $this->traverser = $traverser;
    }

    public function analyze($code) {
        $visitor = new AnalysisVisitor();
        $stmts = $this->parser->parse($code);
        $stmts = $this->traverser->traverse($stmts);

        // do your analysis from $visitor->getNodes();
        // after analysis

        $this->traverser->removeVisitor($visitor);
        return $somethingFromAnalysis;
    }

}
```

With the ::removeVisitor method we can use the same Parser and NodeTraverser instance for each call to Analyzer::analyze while ensuring that each piece of code examined gets its own visitor and ultimately its own collection of nodes analyzed. You could even return the $visitor from the above method to act as a data store of the nodes that we looked at. Another use case (which I can flesh out if you want) is setting a series of multiple visitors while needing to remove one and keep the rest. Without a way to remove the visitor you need to instantiate a traverser object again and reset the visitors.

Additionally this is in part about the completeness of the API. I don't see any reason we shouldn't be able to remove a Visitor.