NOTE: There are other features we can get from adoc too, like automatic generation of the table of contents. That is not part of this PR.
I also didn't verify the results were the same as the markdown version. This PR is mostly a POC to check what is possible.

@bdemers wanna rebase now?

NOTE: subscript doesn't render correctly, I'll continue to look into that. If you see any other issues let me know

Rebased, (force pushed)

1. Is this approach 'worth it' to you - i.e. do you feel it provides both a better authoring mechanism as well as reader/viewer experience?

IMHO, it provides a better author experience, and it allows the version to be set with a property [in the header] (and could be automated at release times).

2. Will existing external links to our documentation still work correctly? I just thought if something references https://github.com/jwkt/jjwt/README.md#some-anchor, everything like that would break, no?

Yes, I made a pass through last week, running something like this (browser console), in both GitHub rendered versions (and diffed them):

for (const a of document.anchors) {
    if (a.name.startsWith('user-content-')) {
        console.log(a.name.substring(13, a.name.length))
    }
}

It seems GitHub prefixes the named anchors with user-content- (I assume to avoid conflicts).
However, using the shortened fragment, e.g. README.adoc#some-anchor works too. (likely some JS to handle the URL fragments 🤷),