Add support for backends and revise parser architecture

> Important: this is not a good example of a PR; a PR should only address, and fix, a single issue. This PR is the size it is because it is an extensive re-architect of the Parsing component for phpDocumentor v3

The goals for this PR are:

1. Remove business logic from the Parse Command class so that it becomes easier to use
   the parser from another context.
2. Decouple the Caching from the Parser so that the caching layer becomes entirely
   optional.
3. Separate the parser coordination from the actual parsing by introducing 'backends';
   these can deal with the actual parsing of individual files and populating the
   ProjectDescriptor.
4. Separate logging from the business logic.
5. Replace Zend Framework components with more light-weight versions to reduce number of packages.
6. Improve performance by disabling Garbage Collection

> Important: In general I do not recommend disabling the Garbage Collection for any application. Testing has shown that the overall performance of phpDocumentor is improved by 10% to 50% by disabling Garbage Collection.
> We have investigated the impact of removing cyclic dependencies but this will impose too many restrictions on the functioning and generated graph of phpDocumentor.

In order to do this the architecture has been changed to make the parser responsible
for collecting files; booting the backends with the configuration and emitting events
so that logging and caching can be event-driven instead of coupled inside the parser.

While parsing a file the parser will find a suitable backend and, if one is found,
pass the file to the backend for parsing and to populate the project descriptor.

Todo:

- [x] Reshape the output of the parser
- [x] Change configuration handling to use Parser only configuration and not global configuration
- [x] Document the various classes
- [x] Rewrite unit tests
- [x] Refactor LegacyNamespaceFilter to use new filtering system
- [x] Do a complete end-to-end test if all features function as expected on several projects
- [x] Move the Document backend prototype into a Document plugin
      
      > During the end-to-end it could be interesting to see if we can codify this using Behat

When this PR is finalized we should consider moving the parser to its own package; this will help with the maintainability of the project, simplify the documentation efforts by making the bits to document smaller and allow others to make use of this component

Since this check seems to be repeated in order to call the dispatch() method, would it hurt to move it into its own class method?  That would remove the duplicate IFs, at least.