feat: Add Query, Header and Cookie attributes for direct Controller injection

[patel-vansh]

Description
This PR introduces attribute-driven parameter resolution for controller methods, allowing HTTP request data to be injected directly into method parameters using PHP 8 attributes.

It enhances CodeIgniter’s controller parameter resolution system while preserving existing routing, form request, and default parameter behaviors.

Controller method parameters can now be annotated with request-source attributes:

• #[Query] → Inject query string values
• #[Header] → Inject HTTP header values
• #[Cookie] → Inject cookie values

Example

class MyController {
    public function index(
        int $id,
        #[Query('limit')] int $limit = 10,
        #[Header('X-Tenant-Id')] string $tenantId
    ) {
        // $limit and $tenant will be fetched from Query and Header respectively.
        // Passing of parameters to attribute is optional, if no $key is passed to attribute, it'll default to name of the parameter itself
    }
}

Currently, its a draft PR for others to see implementation. I haven't added tests or updated userguide yet.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[michalsn]

I'm not convinced this belongs in core, even aside from the implementation issues, which I won't go into here.

CodeIgniter works well when request handling stays explicit and easy to follow. Right now, reading $this->request->getGet('limit') is simple and obvious. With this change, the source of a controller argument becomes less clear, and more of that behavior moves into framework magic.

I'm also worried that this adds a lot of surface area for a fairly small convenience. Once this exists, it will be natural to ask for more variants like #[Post] or #[Json], and more rules around defaults, missing values, filtering, validation, request bodies, and so on. That feels like a lot of extra complexity in a part of the framework that is currently straightforward.

It also seems to overlap awkwardly with FormRequest. We just added a more structured way to work with request data, while this pushes things in the opposite direction by encouraging small implicit injections directly into controller parameters.

So overall, I don't really see the benefit here, at least not enough to justify adding this to the core. But I'd be interested to hear what others think.

[neznaika0]

I don't see any use for it yet either. Everything is in the request. How is this better than calling a request? In addition, there is a segment for the controller :any - it can probably break.

@michalsn, I mentioned this - would anyone want to have similar dependency injections like FormRequest.

[patel-vansh]

Thanks for the thoughtful feedback @michalsn and @neznaika0 . I understand the concerns around keeping request handling explicit and minimizing framework magic. My intent was to explore a lightweight ergonomic option using the existing parameter resolution pipeline, but I see how this could expand scope and overlap with FormRequest.

I appreciate the clarification on project direction. I may explore this as an optional package instead of core.