[markdown] Require balanced parentheses before bare inline link titles - #2768

In LinkSyntax._parseInlineBareDestinationLink, return null immediately when
whitespace ($space, $lf, $cr, $ff) is encountered while inner
parentheses in the bare destination are still open (parenCount != 1).

Why this change is necessary

CommonMark 0.31.2 section 6.3 ("Links") specifies that a bare (non-<>) inline
link destination may not contain spaces or ASCII control characters, and that
any parentheses inside a bare destination must be balanced.

In LinkSyntax._parseInlineBareDestinationLink, parenCount starts at 1 for
the opening ( of [text](... and is incremented/decremented for each
unescaped ( and ) inside the destination. Previously, when whitespace
($space, $lf, $cr, $ff) was encountered, the loop did not check
whether inner destination parentheses were balanced (parenCount == 1) before
calling _parseTitle(parser):

• On an input with an unclosed ( in the destination followed by whitespace and
  a closing ) (with or without a title, such as [a](b( "t")) or
  [a](b( )c)), _parseTitle(parser) left parser.pos on that ),
  parenCount-- decremented parenCount from 2 to 1 (parenCount == 0 was
  false), and break jumped to parser.advanceBy(1) at the bottom of the
  while loop—stepping past ) and continuing to scan as if still inside the
  bare destination. The next ) then decremented parenCount from 1 to 0
  and returned a bogus InlineLink (InlineLink('b(') or InlineLink('b(c')).
• Worse, on repeated inputs like '[a](b( "t")' * n or '[a](b( )' * n (where
  each chunk opens two ( and decrements parenCount only once at the )
  before break steps past it), parenCount grew by +1 per chunk and never
  reached 0, causing the loop to scan across all subsequent chunks to the end
  of the line on every [a]( in O(n^2) time.

How this change works

When whitespace ($space, $lf, $cr, $ff) is encountered in
_parseInlineBareDestinationLink:

1. If parenCount != 1, at least one inner ( opened inside the bare
   destination has not been closed before the whitespace, so we immediately
   return null.
2. Otherwise (parenCount == 1), all inner parentheses in the destination are
   balanced. Once _parseTitle(parser) succeeds (or returns null with
   parser.charAt(parser.pos) == $rparen when trailing whitespace precedes the
   closing )), parser.pos is guaranteed to be on the outer closing ), so
   we return InlineLink(destination, title: title) directly instead of
   decrementing parenCount and breaking back into the loop.

Behavior change

When a bare inline link destination is followed by whitespace and a title, the
destination must have balanced parentheses. CommonMark §6.3 allows parentheses
in a bare destination "only if (a) they are backslash-escaped or (b) they are
part of a balanced pair of unescaped parentheses". Before, [a](b( "t"))
produced a link to b( with the title dropped; now it is literal text, as in
cmark and commonmark.js.

Differential testing

Rendered every input with origin/main and with this branch (GFM extension
set, 30 s per-file timeout) and compared the HTML. Sources:

• pub.dev: 367,926 Markdown files from 93,452 packages
• Real-world docs: 116,231 files from mdn/content, github/docs,
  kubernetes/website, freeCodeCamp, tldr, flutter/website,
  dart-lang/site-www, microsoft/vscode-docs, withastro/docs,
  rust-lang/book, GitHub READMEs, and Wikipedia
• Parser test suites: 6,458 cases from cmark, cmark-gfm, commonmark.js,
  pulldown-cmark, md4c, goldmark, markdown-it, comrak, marked,
  pandoc, and pathological generators
• OSS-Fuzz: 57,716 inputs from the cmark, md4c, and markdown-it-py fuzzers

OSS-Fuzz inputs that sit at the 30 s timeout or the stack limit flip between
runs; every one reported as a new failure was re-run standalone on both trees.
Where the HTML changed, the changed region was also compared with the output of
commonmark.js 0.31 for the same input.

Results:

• 1 real-world difference: a GitHub README with the malformed
  [Cobalt Strike and Tradecraft]([https://hausec.com/…](https://hausec.com/… "…"))
  (the whole [url](url "title") pasted as the destination). main linked
  to the garbage href %5Bhttps://hausec.com/…%5D(https://hausec.com/…; now
  the text [Cobalt Strike and Tradecraft]( is followed by the inner link,
  byte-for-byte what commonmark.js renders for this document.
• 216 OSS-Fuzz inputs changed. For 138 of them the changed region now matches
  commonmark.js where the old output did not; for 1 it is the other way
  around; the rest differ from commonmark.js before and after for unrelated
  reasons (9 of them take commonmark.js itself more than 10 s).
• No differences in pub.dev, the other real-world docs, or the parser test
  suites.
• 3 OSS-Fuzz inputs (191–522 KB) were reported as new timeouts — standalone one takes 4.9 s on main and 3.1 s here, but two of them (both 192 KB of ![)/]( soup from the md4c fuzzer) go from 5.0 s on main to 18 s on this branch. They are the GHSA bracket/delimiter-stack quadratic that is still open on main: before, many of the malformed […](… candidates were accepted as links and consumed; now they are correctly rejected, so every bracket stays on the List-backed delimiter stack and the existing O(n) scans in _linkOrImage run more often. The full [markdown] WIP: Fix quadratic, exponential, and deep-recursion #2737 series (linked-list delimiter stack) parses both inputs in ~0.1 s. For contrast, the input this change is for, '[a](b( "t")' * 8000 (88 KB), takes 82.7 s on main and 70 ms here.
  1 timeout resolved. Cumulative parse time +0.1% (noise).