Having inherited its Application and Routing classes from FastAPI, Air has a lot of extraneous method arguments for route handlers related to response types. This PR removes those arguments, to simplify the API design.

Unfortunately in doing so we violate the Liskov substitution principle, which causes understandable type failures. This PR addresses that by telling type checkers to ignore that error.

I'm not sure breaking LSP is the right approach. Other options include:

1. Construct our own Application/Routing object rather than inherit from FastAPI. But then we lose the ability to turn on making each route path show up in the API docs, which can be useful for more complex projects.
2. Do the above, but mix in typing.Protocol
3. Keep the extraneous arguments as-is so as not to break a core principal of OO design

Note: This doesn't yet touching routing.py, but if we decide to go this path I'll implement it.

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• New feature
  • Core Air (Air Tags, Request/Response cycle, etc)
  • Optional (Authentication, CSRF, etc)
  • Third-Party Integrated (Cookbook documentation on using Air databases or a task manager, etc)
  • Out-of-Scope (Formal integration with databases, external task managers, or commercial services etc - won't be accepted, please create a separate project)
• Refactoring (no functional changes, no api changes)
• Chore: Dependency updates, Python version changes, etc.
• Build related changes
• Documentation content changes
• Other (please describe):

Pull request tasks

The following have been completed for this task:

• Code changes
• Documentation changes for new or changed features
• Alterations of behavior come with a working implementation in the examples folder
• Tests on new or altered behaviors

Checklist

• I have run just test and just qa, ensuring my code changes passes all existing tests
• I have performed a self-review of my own code
• I have ensured that there are tests to cover my changes