[ty] Parse Google docstrings for parameter docs (#25919)
<!--
Thank you for contributing to Ruff/ty! To help us out with reviewing,
please consider the following:
- Does this pull request include a summary of the change? (See below.)
- Does this pull request include a descriptive title? (Please prefix
with `[ty]` for ty pull
requests.)
- Does this pull request include references to any relevant issues?
- Does this PR follow our AI policy
(https://github.com/astral-sh/.github/blob/main/AI_POLICY.md)?
-->
## Summary
<!-- What's the purpose of the change? What does it do, and why? -->
This refactors how we extract parameter documentation from Google-style
docstrings. It replaces the existing regex-based scanner in
`ty_ide/src/docstring.rs` with a parser that should strictly improve
parameter documentation extraction along the following dimensions:
- We will now recognize parameters from `Keyword Args` and `Other Args`
sections (as well their other common spellings), where previously we
only recognized parameters from `Args` and `Parameters` sections.
- We now respect PEP 257 indentation and container boundaries, thereby
ignoring parameter-like text that appears inside Markdown fences/lists,
doctests, and reStructuredText directives, field lists, and literal
blocks.
- We now recognize continuation prose in parameter documentation more
consistently.
- We now extract docs for all parameters in a comma-separated list.
In addition, to those immediate improvements, this new section visitor
provides the source text range tracking that will allow us to render
Google-style docstring as markdown in an [upcoming
change](https://github.com/astral-sh/ruff/pull/26599).
Please note that I have intentionally biased this parser towards
successfully parsing shapes that were actually found in the wild during
a corpus review of popular public repositories that use Google-style
docstrings. As such, there are theoretically possible shapes that we do
not bother to support because they are very unlikely to occur in real
docstrings. I think this is an acceptable compromise in favour of
maintainability.
## Test Plan
Please see included tests.
<!-- How was it tested? -->
