Feat/add options support

[Shepard2154]

Summary

This PR adds automatic OPTIONS request support for ASGI routes created with @get and @post decorators. This enables CORS preflight requests from browsers without requiring manual OPTIONS route definitions.

Changes:

1. Automatic OPTIONS request support - Added automatic OPTIONS handling in HttpHandler that returns 204 No Content with basic CORS headers. CORS headers are also added to main responses (GET, POST) when Origin is present in the request. This provides minimal CORS support: returns the Origin from the request, allows route methods, and the Content-Type header.

2. Tests - Added parameterized test test_options_request to verify OPTIONS handling for both GET and POST routes.

3. Documentation - Added a note about automatic OPTIONS support in ASGI documentation.

Result:
Browsers can now perform CORS preflight requests without manually defining OPTIONS routes. This provides basic CORS support for simple use cases.

Code examples:
OPTIONS requests are automatically handled for all routes created with @get or @post decorators:

from faststream.nats import NatsBroker
from faststream.asgi import AsgiFastStream, AsgiResponse, get
from faststream.asgi.types import Scope

broker = NatsBroker()

@get
async def liveness_ping(scope: Scope) -> AsgiResponse:
    return AsgiResponse(b"", status_code=200)

app = AsgiFastStream(
    broker,
    asgi_routes=[("/health", liveness_ping)],
)

You can test OPTIONS requests using curl:

curl -X OPTIONS http://localhost:8000/health \
  -H "Origin: http://example.com" -v

Resolves #2658

Type of change

Please delete options that are not relevant.

• New feature (a non-breaking change that adds functionality)
• This change requires a documentation update

Checklist

• My code adheres to the style guidelines of this project (just lint shows no errors)
• I have conducted a self-review of my own code
• I have made the necessary changes to the documentation
• My changes do not generate any new warnings
• I have added tests to validate the effectiveness of my fix or the functionality of my new feature
• Both new and existing unit tests pass successfully on my local environment by running just test-coverage
• I have ensured that static analysis tests are passing by running just static-analysis
• I have included code examples to illustrate the modifications

[borisalekseev]

@Shepard2154 hello!

Thanks for the PR. I have a few concerns before we merge this as-is:

1. No actual CORS implementation
   Returning responses to OPTIONS requests alone doesn’t implement CORS. It described in mdn and implemented in starlette, for example.

2. Not opt-in / always enabled
   As proposed, the behavior seems to be applied automatically for everyone. That’s a potentially breaking or at least surprising behavioral change, especially for users who want full control over routing/HTTP semantics, or who don’t want OPTIONS automatically answered at all. This feels like something that should be configurable / explicitly enabled.

I think that ASGI middleware support might be a better foundation.
Instead of baking OPTIONS (and potentially partial CORS behavior) into the core app, it might be better to support plugging in ASGI middleware. Then users can add starlette.middleware.cors.CORSMiddleware (or any other ASGI middleware) themselves, which is a standard, flexible solution and avoids forcing one behavior on all users.

If you’re open to it, I’d strongly prefer moving in the direction of “ASGI middleware support + documented CORS middleware example” rather than implementing OPTIONS handling universally in core.