An inline after a link whose destination wraps is reported a line early

```markdown
a [b](
http://x.com/) c
www.y.com d
```

MD034 reports the `www.y.com` of line 3 at `2:1`, which is inside the previous line's link destination. The document has no bare URL there, and the one it does have is not named.

comrak measures the inlines after a link whose destination wraps to the next line from a line and a column that are both a line behind. `Document::line_text` knows about it — it is the first of the two cases its doc comment names, and `is_source_of` is what detects it, by reading the line back and asking whether `CommonMark` could have built the literal out of it. Rules that go through `line_text` fall back to the literal there rather than report out of the wrong line.

`Document::written_position` has no such check. It corrects a column for the pipes comrak unescaped out of a table cell and returns everything else unchanged, so a position comrak measured against the wrong line is returned against the wrong line. MD033, MD034, MD038 and MD039 all report through it.

Not a regression: `mado` 0.3.2 reports `2:1` for the same document written with `http://y.com/` on line 3 instead. What #418 changed is the reach — a `www.` host is a bare URL to GFM and was not one to the URL scanner mado used before, so the shape above is newly reportable and newly wrong about where.

Worth deciding whether `written_position` should take the literal the way `line_text` does, so that a position it cannot read the line for is answered as unknown rather than as a line the document does not have it on.

Reproduce the sample in the issue, then compare Document::written_position with Document::line_text and its is_source_of check for wrapped link destinations. Trace the MD033, MD034, MD038 and MD039 reporting paths; done means positions are not reported against the preceding line and the behavior for positions whose source line cannot be read is covered.

Rédigé par le modèle d'indexation à partir du texte de l'issue.