[feature] Integrate PHP-DI for dependency injection control

[coisa]

Problem

Currently, the DevTools application manages dependencies through direct instantiation, making it difficult to test, extend, and maintain different configurations. There is no unified dependency injection container, which leads to tight coupling between components.

Proposal

Integrate PHP-DI (PHP Dependency Injection Container) to provide centralized dependency management, making the application more testable, extensible, and maintainable.

Goals

• Centralize dependency management through PHP-DI container
• Enable easier mocking and testing of components
• Allow configuration-driven instance creation
• Support lazy loading of expensive services
• Provide clearer dependency graphs

Expected Behavior

• Application services should be defined in a central configuration
• Dependencies should be injected through constructors
• Container should be configurable via PHP-DI definitions
• Existing functionality must remain fully compatible

Implementation Strategy

1. Add php-di/php-di as a dependency to composer.json
2. Create a container configuration that builds the existing services
3. Refactor command classes to receive dependencies via constructor injection
4. Ensure backward compatibility with existing command registration
5. Update tests to use the container or mock dependencies appropriately

Scope

• Add PHP-DI dependency
• Create container definitions
• Refactor services to use constructor injection
• Update affected tests
• Update documentation

Non-goals

• Rewrite existing working code without clear benefit
• Change public APIs beyond adding container configuration

Benefits

• Testability: Easier to mock dependencies in unit tests
• Extensibility: Users can override or extend definitions
• Maintainability: Clear dependency graph, centralized configuration
• Flexibility: Support for lazy loading, factory definitions

Acceptance Criteria

Functional Criteria

• PHP-DI is installed and usable
• Container provides all existing services
• Commands receive dependencies via constructor injection
• All existing tests pass
• No breaking changes to command-line interface

Architectural / Isolation Criteria

• All service definitions MUST be in a centralized configuration file
• Container configuration MUST support environment-specific overrides
• Command classes SHOULD receive dependencies via constructor injection
• New services MUST be added to container definitions, not instantiated inline
• All container-provided services MUST have corresponding tests
• Documentation MUST be updated to reflect the new architecture

Additional Notes

Namespace modifications can be performed to better organize the project, provided that:

• All documentation (README, docs/, wiki) is updated accordingly
• All tests are adjusted to reflect the new namespace structure
• GitHub Actions workflows are updated if needed
• The composer.json autoload configuration is updated