Integrations separate CI workflows

[p1c2u]

This pull request introduces dedicated GitHub Actions workflows for running integration tests against various Python web frameworks and libraries, improving the granularity and maintainability of CI for integration tests. Additionally, the main test workflow is updated to exclude these integration tests, delegating their execution to the new workflows.

Continuous Integration Improvements:

• Added separate GitHub Actions workflows for integration testing of the following frameworks and libraries, each running on multiple Python versions: aiohttp (integration-aiohttp.yml), django (integration-django.yml), falcon (integration-falcon.yml), fastapi (integration-fastapi.yml), flask (integration-flask.yml), requests (integration-requests.yml), starlette (integration-starlette.yml), and werkzeug (integration-werkzeug.yml). [1] [2] [3] [4] [5] [6] [7] [8]
• Updated the main python-test.yml workflow to exclude the tests/integration/contrib directory from its test run, ensuring that integration tests are only run in their respective dedicated workflows.

In general, you should explicitly declare permissions for the workflow or for each job, granting only the minimal access required. For this workflow, both jobs (core_tests and static_checks) only need to read the repository contents and use external services (PyPI, Codecov). They do not appear to need any write access to the GitHub API. The best fix is to add a top-level permissions block that applies to all jobs, setting contents: read. This documents intent and ensures the token cannot be used to modify repository contents even if defaults are broad, without changing any existing functionality.

Concretely, in .github/workflows/python-test.yml, add a new root-level permissions: mapping, aligned with name: and on:, for example on a new line after name: CI / Core / Tests. The content should be:

permissions:
  contents: read

No other imports, steps, or job definitions need to change.