PHP parser

This is a work-in-progress towards fixing #195. Commits are still a bit messy, tests are still failing, code isn't completely cleaned up, but hopefully it can serve for some preliminary review or discussion. You have been warned ;-)

*Prose explanation on what this PR does (added 2014-12-03):*

First of all, please keep in mind that this PR only uses PHP-Parser for VIP-scanner's analyzers (as used to display the section in the plugin's "Analyze" tab, or via `wp vip-scanner analyze-theme`), i.e. to display code elements like namespaces, functions, classes (and contained methods), and 'resources' (scripts, styles, filters etc, taken from the parameters that functions like `add_filter()` etc. are called with). The checks (which make up the 'Scan' tab, or the `wp vip-scanner scan-theme` output) aren't touched by this PR yet; that's what #218 is about.

Now on to this PR. First of all, a little wrap-up of how the `Analyze` tab output was generated before:

* VIP-scanner had its homegrown parser (in vip-scanner/class-token-parser.php) based PHP's own tokenizer. That parser didn't really yield a full-fledged AST, but rather a (non-recursive) array of arrays whose items were attributes, like so:

        [1] => Array
            (
                [type] => function_call
                [name] => _e
                [args] => Array
                    (
                        [0] => 'Copyright'
                        [1] => 'smartbiz'
                    )
                [path] => 
                [line] => 10
            )

* Those were then grouped into a hierarchy of three or four levels: first by their `type`, then by their `path` ( = basically their scope, mostly in order to discern elements of the same `type` and `name`), and finally by their `name`. (This was done by class `AnalyzedPhpFile` in vip-scanner/class-analyzed-php-file.php). 
* Afterwards, they were run through the `PhpAnalyzer` (for PHP code elements), `CustomResourceAnalyzer` (for filters/scripts/styles etc) and `ThemeAnalyzer` classes (this one was actually analyzing CSS files); all three classes are found in the analyzers directory.
* More precisely, thoses analyzer classes employed the classes in the renderers directory to render individual types of elements for output, like `FunctionRenderer`, and which plugged into the hierarchy generated by AnalyzedPhpFile. They were all based on `AnalyzerRenderer`, and basically iterated through the elements' attributes as obtained from `AnalyzedPhpFile`.

The PR changes this as follows:

* PHP files are parsed using PHP-Parser, directly from within `AnalyzedPhpFile`, which yields an AST; [here](https://gist.github.com/ockham/09845e12d48d0d7bc258)'s an example of what its nodes look like. It's obviously different from before, but most information is still readily availabe.
* Some information, though, we need to generate on our own. This is where node visitors (found in the `visitors` directory) come in. They're run on every node while the tree is being traversed (also from within `AnalyzedPhpFile`). There's a visitor to add the scope (`path`) as an attribute to nodes; there's another one to group it into the same kind of `type`/`path`/`name` hierarchy we had before and which we still need to display the elements grouped by their types.
* But something's different; not every piece of information is conveyed by array keys and values anymore. Instead, the nodes generated by PHP-Parser have class methods depending on their type, e.g. nodes of type `PhpParser\Node\Stmt\ClassMethod` have class methods `isPublic()`, `isProtected()`, `isPrivate()`, `isAbstract()`, `isStatic()` etc. This means we need to adapt test-AnalyzedPHPFile.php, BTW.
* Now it wouldn't make much sense to just emulate the old attributes by running all those class methods and generating array items `visibility` => `public` etc like we used to have. (There's a lot of other examples apart from class methods' visibility, but I figure this one's quite illustrative.)
* Instead, as all required information is conveyed by the node itself, I decided to turn all `Renderers` except for `AnalyzerRenderer` into `Processors`. It's those `Processors`' job to, well, process information gained from a node for output, but independently of the actual rendering details. Thus, the `Processors` aren't based on `AnalyzerRenderer` (which is renamed to `ProcessorRenderer`) anymore.
* (Just to note why I think this separation of processing and rendering is cleaner than the old way: `ProcessorRenderer` still takes care of both HTML and terminal output, using a `$display_args['bare']` parameter. I intend to split it into `HtmlRenderer` and `TerminalRenderer` once this PR is merged. )
We need to figure installation/updates/packaging before merging.

Personally, I am OK with submodules for now, if we document them in the installation procedure. We’re lucky that puppet’s `vcsrepo` supports submodules by default, but others might be using it in another way.

We need to make sure if somebody wakes up to an empty `vendor/`, they will get a proper error message.

@joshbetz, what’s the current process of packaging and committing to the WordPress.org repo? We should make sure we commit `vendor/`, too.