[NFR]: Framework-neutral integration seam: boot and response injection without Mvc\Application

[niden]

Summary

The debug bar can only be booted and injected against a Phalcon\Mvc\Application. This blocks non-MVC applications - notably ADR (Phalcon\ADR) - from using it at all. Introduce a framework-neutral integration seam so any application can boot the bar and inject it into an HTML response, keeping the current MVC path as a thin wrapper.

Current coupling

• Phalcon\DebugBar\Provider::__construct(Application $app, array $config) requires a Phalcon\Mvc\Application, and boot() reaches into it through $app->getDI() and $app->getEventsManager().
• Response injection is attached to the MVC application:beforeSendResponse event inside Provider::boot() (the ResponseListener).

Why it does not work for ADR

• The ADR container is Phalcon\Container\Container (implements Collection, not Phalcon\Di\DiInterface), so getDI() and the ?DiInterface parameters do not fit.
• The ADR stack never fires application:beforeSendResponse. The response is available at Event::APPLICATION_AFTER_HANDLE (Phalcon\ADR\Application) and is written out by the ADR emitter.
• Data collection (the collectors' event vocabulary) is a separate concern tracked in ticket 2; this ticket covers only the boot and injection seam.

Proposed direction

• Extract a neutral core that takes only what it needs: an events manager (or none), a Phalcon\Http\RequestInterface (or none), and an optional config source - no Phalcon\Mvc\Application, no Phalcon\Di\DiInterface.
• Provide a neutral entry point to inject the rendered bar into a given Phalcon\Http\ResponseInterface, callable at each framework's own response-emission point:
  • MVC: the existing application:beforeSendResponse listener.
  • ADR: a listener on APPLICATION_AFTER_HANDLE, or an emitter hook.
• Keep Phalcon\DebugBar\Provider(Application $app, ...) as a thin convenience wrapper over the neutral core, so MVC behavior is unchanged.

Acceptance

• The bar boots and injects into an HTML ResponseInterface in an application that has neither a Phalcon\Mvc\Application nor a Phalcon\Di\DiInterface.
• The existing MVC integration (as used by phalcon/vokuro) is unchanged.