API documentation is missing an explanation of CMARK_NODE_CUSTOM_BLOCK and CMARK_NODE_CUSTOM_INLINE

The API documentation for cmark (e.g. in the cmark.3 man page) does not explain the
purpose or proper use of the CMARK_NODE_CUSTOM_BLOCK and CMARK_NODE_HTML_INLINE constants from the cmark_node_type enum. (Actually, it does not explain the purpose or use of any of the cmark_node_type constants; but all the others correspond fairly obviously to blocks or inlines in the CommonMark spec.)

I see that the changelog contains some description of them:

• [API change] Added CUSTOM_BLOCK and CUSTOM_INLINE node types.
  They are never generated by the parser, and do not correspond
  to CommonMark elements. They are designed to be inserted by
  filters that postprocess the AST. For example, a filter might
  convert specially marked code blocks to svg diagrams in HTML
  and tikz diagrams in LaTeX, passing these through to the renderer
  as a CUSTOM_BLOCK. These nodes can have children, but they
  also have literal text to be printed by the renderer "on enter"
  and "on exit." Added cmark_node_get_on_enter,
  cmark_node_set_on_enter, cmark_node_get_on_exit,
  cmark_node_set_on_exit to API.

But that information really should be in the API documentation, not in the changelog - without it, the API documentation cannot be understood. And because the changelog uses the abbreviation CUSTOM_BLOCK instead of spelling out CMARK_NODE_CUSTOM_BLOCK in full, searching for CMARK_NODE_CUSTOM_BLOCK in the repository will never bring up that changelog entry, making it difficult for developers to work out what it was intended to do.

If the man page is the only place that would need updating, then I'd be happy to create a PR to add the changelog information to the man page, if desired.

Start with man/man3/cmark.3 and locate the cmark_node_type and custom-node API documentation, then compare it with the relevant entry in changelog.txt. Done means the documentation explains that CMARK_NODE_CUSTOM_BLOCK and CMARK_NODE_CUSTOM_INLINE are inserted by filters, are not generated by the parser, and describes their children, literal text, and on-enter/on-exit behavior.