Add blank lines after docstring-only functions in stub files outside overload groups

[AlexWaygood]

Description

In .pyi stub files, Black currently does not consistently separate a function or method with a docstring-only body from the statement that follows it. It already inserts a blank line when another function definition follows directly, but not when the next statement is a comment, conditional block, variable annotation, or other non-function statement:

# Before

class Example:
    def foo(self) -> None:
        """Documentation."""

    def method(self) -> None:
        """Documentation."""
    # comment for the next member
    attr: int
    def method2(self) -> None:
        """Documentation."""
    if sys.version_info < (3, 12):
        def method3(self) -> None:
            """Documentation"""
    attr: int

This PR adds a new preview feature (pyi_blank_line_after_function_docstring) that enforces a blank line after a function or method body that consists only of a docstring in .pyi files, making Black more consistent about inserting blank lines after function docstrings:

# After (with `--preview`)

class Example:
    def foo(self) -> None:
        """Documentation."""

    def method(self) -> None:
        """Documentation."""

    # comment for the next member
    attr: int
    def method2(self) -> None:
        """Documentation."""

    if sys.version_info < (3, 12):
        def method3(self) -> None:
            """Documentation"""

    attr: int

The implementation teaches EmptyLineTracker to detect this case when the previous statement was a definition whose body ended in a docstring. It preserves the existing special handling for same-name decorated functions, so @overload groups and @property setters are still kept together without extra blank lines between the related definitions.

Motivation

Most libraries don't include docstrings in their stub files, but it's increasingly popular to monkeypatch them in as a build step using tools like docstring-adder and docify. This is what ty does for its vendored typeshed stubs, for example; this patch greatly improves readability for our vendored, docstringified stubs, in my opinion. An example branch with the formatting from this PR applied is here: https://github.com/astral-sh/ruff/compare/main...AlexWaygood:alex/new-stub-formatting?expand=1

Checklist - did you ...

• Implement any code style changes under the --preview style, following the stability policy?
• Add an entry in CHANGES.md if necessary?
• Add / update tests if necessary?
• Add new / update outdated documentation?

[github-actions]

diff-shades results comparing this PR (444c0fd) to main (c77093e):

--preview style: no changes

--stable style: no changes

---

What is this? | Workflow run | diff-shades documentation