Reimplement the Antora asciidoctor html5 converter using an interceptor model
Guillaume, in asciidoctor-pdf.js, implemented an html5 converter using an interceptor or composition model rather than inheritance or directly modifying the class (I'm not sure how to describe the rubyisms in the current implementation). This can be done for the Antora html5 converter as well. To me, the advantages are:
- more comprehensible by non-Opal experts
- allows easily chaining multiple interceptors for different purposes. For instance, to adapt asciidoctor-pdf.js to antora, more modifications appear to be needed. With this interceptor model, the antora and pdf interceptions can be cleanly separated and distinguished.
Implementation notes: Judging by the asciidoctor-pdf.js implementation, this will be easier with asciidoctor 2. I think only a convert and not a $convert method on the adapter will be needed. I suspect more Opalisms can be removed from the interceptor code, but I didn't try. I've moved the setup of the ref interpreters into the interceptor; IMO there's no particular reason load-asciidoc should know how the interceptor is going to use the context information. Supplying it all leaves room for adding other interceptors that need additional information.