Add parser and writer factories to prepare for future http protocols

[Vizonex]

What do these changes do?

For preparation of http/2 and http/3 I have devised a plan to slowly work h2 and aioquic into aiohttp which involves
making abstract bases or implementing type factories into the program so that http/1.1, http/2 and http/3 can be interchangeable in a future update.

Are there changes in behavior for the user?

There shouldn't be any changes yet for users working at a higher level, however users will start notice new arguments appearing
when utilizing things from a ClientSession at a lower-level, these for now can be undocumented and left ignored and anyone curious as to why should be able to find this pull request with ease. I have planned this migration to be done slow and steady so that newer protocols can be introduced soon.

Is it a substantial burden for the maintainers to support this?

Like I have stated above this process will need to be done slowly if we want http/2 http/3 in the future. My goal is to have at least 1 of these protocols added and fully working with clients and servers before 2027 which should be a reasonable amount of time to complete this goal I had in mind.

Related issue number

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • The format is <Name> <Surname>.
  • Please keep alphabetical order, the file is sorted by names.
• Add a new news fragment into the CHANGES/ folder

  • name it <issue_or_pr_num>.<type>.rst (e.g. 588.bugfix.rst)

  • if you don't have an issue number, change it to the pull request
    number after creating the PR

    • .bugfix: A bug fix for something the maintainers deemed an
      improper undesired behavior that got corrected to match
      pre-agreed expectations.
    • .feature: A new behavior, public APIs. That sort of stuff.
    • .deprecation: A declaration of future API removals and breaking
      changes in behavior.
    • .breaking: When something public is removed in a breaking way.
      Could be deprecated in an earlier release.
    • .doc: Notable updates to the documentation structure or build
      process.
    • .packaging: Notes for downstreams about unobvious side effects
      and tooling. Changes in the test invocation considerations and
      runtime assumptions.
    • .contrib: Stuff that affects the contributor experience. e.g.
      Running tests, building the docs, setting up the development
      environment.
    • .misc: Changes that are hard to assign to any of the above
      categories.

  • Make sure to use full sentences with correct case and punctuation,
    for example:

    Fixed issue with non-ascii contents in doctest text files
    -- by :user:`contributor-gh-handle`.

    Use the past tense or the present tense a non-imperative mood,
    referring to what's changed compared to the last released version
    of this project.

[codspeed-hq]

CodSpeed Performance Report

Merging #11717 will not alter performance

_{Comparing Vizonex:future-protocol-support (747a81e) with master (056d929)}

Summary

✅ 59 untouched

[Dreamsorcerer]

This might make sense, but I think we probably want to see a followup PR with an initial implementation of another factory before we consider merging this one.