Add GFM alerts extension

[ia3andy]

Note

I have used Claude to code most of it, I am currently reviewing the generated code which seems to be overall valid. I've requested to follow the pattern of existing extensions (and compare to other implementations of this feature).

Summary

• Adds new extension module for GitHub Flavored Markdown alerts
• Implements alert detection as a PostProcessor (transforms BlockQuote nodes into Alert nodes after parsing)
• Includes HTML and Markdown renderers
• Supports all five standard GFM alert types: NOTE, TIP, IMPORTANT, WARNING, CAUTION
• Case-insensitive type matching ([!note], [!Note] work like [!NOTE])
• Supports custom alert types and title overrides via builder API (e.g., for localization)
• Empty/whitespace-only alerts render as normal blockquotes (matching GitHub behavior)
• Alerts only at document level (not inside list items or nested blockquotes, matching GitHub)

Test approach

• AlertsSpecTest — parameterized spec-based tests from alerts-spec.txt, expectations verified against GitHub Markdown API (gh api markdown -f mode=gfm)
• AlertsTest — custom types, builder validation, AST assertions
• AlertsMarkdownRendererTest — roundtrip rendering tests

Changes from review

• Rewrote from custom BlockParser to PostProcessor approach
• Added case-insensitive type matching
• Allow overriding standard type titles
• Removed unnecessary TextContentRenderer (core handles it)
• Constructor injection for Alert (immutable type, no public setter)
• Moved STANDARD_TYPES from Alert node to AlertsExtension
• Removed getCustomTypes() config leak from public API
• Fixed visitor traversal (early return after successful conversion)
• Removed dead code (capitalize fallback)

Closes #327

[ia3andy]

I've been through the code which seems good to me so I can say I am taking responsibilities for it like my own. Still, another set of eyes would be good :)

[ia3andy]

@robinst any thought ?

[robinst]

Some first comments, mostly around parsing and edge cases.

I was curious how GitHub implements this in cmark-gfm, and the answer seems to be that they don't:

github/cmark-gfm#350 (comment)

Alerts are not implemented in this project. They don't relate to their parser. They don't relate to syntax. So they're not here.

They are implemented as a post processing step on a sort of "DOM" version of the resulting document.

Can you explore what the implementation would look like as a PostProcessor instead? That has the advantage of not having to copy all the parsing logic from block quotes. (From the edge cases with nesting I commented about, it seems like they only look at top-level nodes.)

[ia3andy]

Thanks for the review! That all makes sense, will have a look soonish :)

[ia3andy]

I made all the changes, I am currently generating a small jbang script to generate the spec from gh api result, not needed but cool :)

[ia3andy]

@robinst it is ready for another review thanks!

[robinst]

More feedback. Getting closer, but I think we can still simplify.

Neat idea to generate the test data by using the gh CLI.

[ia3andy]

All review feedback has been addressed:

PostProcessor simplification:

• Replaced AbstractVisitor with direct iteration of Document children
• Removed isContentWhitespaceOnly (parser never produces content nodes for whitespace-only continuations)
• Removed redundant markerText/literal variables
• Restructured afterMarker checks to avoid repeated instanceof

Code cleanup:

• Added Locale.ROOT to toUpperCase() calls
• var throughout all main source files
• Single get()+null check instead of containsKey()+get() in renderer
• Added proper Node import in AlertNodeRenderer
• LinkedHashMap → HashMap in AlertsExtension

README:

• Fixed outdated custom type documentation
• Added screenshots (with and without icons)
• Aligned examples with AlertsExample.java