[ty] Introduce shared primitives for parsing backticks in docstrings

[lerebear]

Summary

This refactors the code span parsing we do in docstrings around a cursor-based scanner and explicit ranged backtick runs and spans. Ultimately, this serves two purposes:

1. To remove duplicated offset arithmetic from inline-link and trailing-parenthetical parsing.
2. To expose an iterator over backtick-delimited fragments of text for downstream normalization.

Test plan

See included tests.

[MichaReiser]

Nice.

Codex claims that the backtick lexer is overly strict and doesn't correctly recover from invalid backticks

`unmatched ``code``

should be

vec![
    ("text", "`unmatched "),
    ("span", "code"),
]

Escaping only escapes the first backtick, not all of them

\``code`

Expected

vec![
    ("text", r"\`"),
    ("span", "code"),
]

[lerebear]

Codex claims that the backtick lexer is overly strict and doesn't correctly recover from invalid backticks
Escaping only escapes the first backtick, not all of them

Those findings are both accurate, but I don't think they're worth fixing at the moment:

1. In my brief explorations, they seem to require a significantly more complex design.
2. Those patterns appear to occur in real docstrings infrequently.
3. When they do occur, we generally just risk displaying a few extra backticks literally, which is incorrect but harmless.

Of course we can readjust in the future if we receive complaints.