[WIP] Finishing the planned functionality.

- The profiler and related parts are now located under the Profiler namespace.
- Its uses the event manager to decouple functionality like the collecting 
  process from the profiler.
  - New profiler events: `bootstrap`, `collect`, `access`, `finish`
  - The `bootstrap` event allows modules to do things only if the profiler is
    enabled. The matcher will listen to this event, with a higher priority, and
    stops further propagation if the defined pattern does not match.
  - The `collect` event is used to start the collecting process. It will also 
    be used flush the reponse early, if possible.
  - The `access` event only occurs when any profiled data should be send or was 
    requested from the browser, like the toolbar. It will be triggered in the 
    `GuardListener` or during the controller dispatch (see ZendDeveloperTools' 
    `AbstractActionController`). If the access was denied (
    `ProfilerEvent::denyAccess`), the rendering will be interrupted or in the 
    controller case, it will return a 404 response. This is done to prevent 
    the module from exposing itself.
  - The `finish` event is used to send the toolbar/FirePHP console output or 
    save the collected data.
- The toolbar will support ajax based application, which is currently not the 
  case, but the initial toolbar loading will still happen without JavaScript.
- Simplified the `CollectorInterface`. A collector can now implement additional
  features such as `TemplateProviderInterface`. 
- It is now possible to let the matcher run later if desired, controlled by the 
  options. Running the matcher later may introduce some additional overhead, 
  depending on what modules do during the `boostrap` event. Doing the matching 
  later allows more possible matchers. If a matcher only supports late 
  matching, the matcher should implement `LateMatchingInterface` which will be 
  recognized during the matching process and the matcher will throw a
  `MatcherException` exception.