Fix qvalue parsing

[jcharlytown]

Fixes #2751. Introduce proper regex for quality values as specified by RFC9110

• fixes parse_options_header rejects q values "0" and "1" #2751

Checklist:

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.

[jcharlytown]

Question: Introducing a regex which tests explicitly for RFC9110 makes the parsing very strict. Alternative would be to just allow plain floats and plain ints. I'd be happy to change the PR if needed

[pgjones]

I think this is good, and the right level of strictness. Yet, I also believe I'll change my mind after we find users caught out by it :conflicted: . If we do stay this strict, I don't think it can be a patch release.

[davidism]

I like the idea of naming this specifically as _qvalue instead of _plain_float, since _plain_float only ended up being used in that one place anyway. I'll lift the decimal length restriction though and make it part of the next fix release.

[ThiefMaster]

I think this is good, and the right level of strictness.

I think generally you should be lenient in what you accept and strict in what you generate. Is there really a good reason to become more strict there when parsing?

[davidism]

Nowadays I've observed more projects and maintainers leaning towards not accepting everything, because otherwise nothing gets fixed and no client/server can ever really conform to the standards. But here it doesn't really matter either way (I doubt most clients use more than one decimal place in practice), so I'm just staying lenient.