- Add `aio` namespace for async functions (firebase_functions.aio.https_fn)
- Support both on_request and on_call async decorators
- Extract shared business logic to avoid code duplication:
  - _validate_on_call_request_headers()
  - _process_on_call_request_body()
  - _format_on_call_response()
  - _format_on_call_error()
  - _add_cors_headers_to_response()
- Add asgi field to ManifestEndpoint for async function deployment
- Implement proper CORS handling for async functions
- Add comprehensive tests for async functionality
- Use type overloads to maintain type safety for both sync and async paths
- Fix header lookup to be case-insensitive for compatibility

This is the first phase of async support, starting with HTTP functions.
Future PRs will add async support for other trigger types.

- Remove restriction that aio decorators only accept async functions
- ASGI can handle both sync and async functions (runs sync in thread pool)
- Update async wrappers to check if function is async or sync before calling
- Add tests to verify sync functions work correctly in aio namespace
- This makes the API more flexible and user-friendly

Users can now use firebase_functions.aio for any function they want to run
in the ASGI stack, regardless of whether it's sync or async.

- Update copyright year to 2025 for newly created files
- Update async.md to reflect implementation choices:
  - Document namespace-based approach using aio module
  - Show that aio namespace accepts both sync and async functions
  - List completed work and remaining tasks
  - Update examples to show correct usage