Recognize the signature block in docstrings that put the summary first

The plugin extracts two things from every referenced docstring: the *signature* and the *brief* (or "summary")

It currently assumes the format that the Julia manual uses, where the docstring opens with the signature code block.

Personally, I've long advocated for an alternative style, where a docstring opens with the summary, and is followed by the signature code block. I apply this consistently in all my projects, e.g., all docstrings in [DocumenterCitations.jl](https://github.com/JuliaDocs/DocumenterCitations.jl) look like this:

````julia
"""Expand a [`CitationLink`](@ref) into style-specific markdown code.

```julia
md_text = format_citation(style, cit, entries, citations)
```

returns a string of markdown code that replaces the original citation link, rendering it for the given `style`.
"""
function format_citation end
````

The summary is the first paragraph, the signature is the block after it, and the prose below the block continues the sentence the block starts ("`md_text = format_citation(…)` returns a string of markdown code").

The reason I prefer the format is exactly because I think there is a lot of potential for docstrings containing an identifiable summary sentence – the current documentation stack underutilizes the feature, but this plugin relies on it explicitly. Which might be a motivation for my format becoming more widespread!

Right now, the signature block is not the docstring's leading element, so the plugin does not see it as a signature. As a consequence:

1. Every such docstring gets a build warning telling me to restructure it:

```
┌ Warning: CodeBlocks: the docstring for `DocumenterCitations.format_citation` does not start
│ with a signature code block; tooltips fall back to the synthesized signature
│ `format_citation`. Start the docstring with the indented signature (the Julia convention):
│ """
│ format_citation
│
│ ...
│ """
```

2. Tooltips show a signature synthesized from the method object rather than the one I wrote.

3. The signature block renders as ordinary example code: it gets a line-number gutter and a permalink, and its identifiers link as uses rather than in a binding context. Visually it stops reading as a header.

The brief, on the other hand, already comes out right, since it is the first paragraph either way.

## Proposal

Take the brief from the docstring's first prose paragraph and the signature from its first code block, in whatever order the two appear. Both conventions then work without either being privileged, and neither the extraction nor the rendering needs to know which one an author is following.

If this is "controversial" (you suspect it would lead to a lot of code blocks in the wild being mis-identified as a signature), this could be behind a flag. As a middle ground, I could also see placing some bounds on how far down we search for a signature block (preventing example code from being promoted to a signature). Requiring the signature block to be adjacent to the summary paragraph (leading, or directly after one paragraph) would be sufficient for both formats.

Locate the plugin code that extracts the signature and brief from referenced docstrings, then inspect existing tests covering docstring parsing and rendering. Add coverage for both signature-first and summary-first layouts, including the adjacent prose case. Done means both conventions produce the intended brief, signature rendering, and no warning.

Written by the indexing model from the issue text.