Refactor template parser

[emeka]

Finally the PR for the document service. It is a big PR as the XML/Template parsing was fully replaced and the renderer/compiler code has been refactored.

The best way to review is to start from the API. The two entry points that have been changed are /compile and /vars.

The old XML parsing that was reimplementing a XML parser and generating a customer DOM tree where nodes were XML and JTwig templates nodes. It has been replaced by a standard java StaX XML parser and a template extractor which is responsible of finding and interpreting template code elements. The two parts are clearly separated: a TemplateParser (in this case a JTwigParser) handles the template and a TemplateExtractor class handle the generic extraction of the template code that is inside the visible document text. The result must be a well formed template made of XML and template instructions.

The TemplateParser responsibility is to recognize the template instructions in the characters elements of the XML document, to maintain a state machine whose states indicated if we are in the XML, a code element, a content element or a comment, and tracks the current code block. In addition, the TemplateParser will segment the XML characters element to isolate the template instructions from the other document texts and simplify downstream event processing.

The TemplateExtractor will read XML events, send characters to the TemplateParser, interpret the new parser state, move XML elements out of the template instructions, ensure that matching XML start and end elements are located in the same template code block.

The whole XML handling has been migrated to an event pipeline composed of XMLEventProcessor's. Therefore the template extractor, image adjuster, empty element remover, ODT manifest processor, template and image variable extractors implement the XMLEventProcessor interface. It is now possible to easily add more XML processing in the chain and still understand the full system. Also, each processor can easily be testes separately.

The XML processor is only part of the full document service. It is responsible of actually rendering an ODT document used as a document template, to an other valid ODT document after executing the template with given data context. The ODT document is then formatted using a DocumentCompiler. At the moment, only the LibreOffice ODTDocumentCompiler is implemented. the compiler is responsible to read the input files, render the template, gather the additional assets including additional fonts, and then format the rendered document using the a TemplateFormatter, currently the LibreOfficeAssistant which was not changed in this PR.

The ODTCompiler and the associated ODTRenderer (renamed from the old ODTContext) have been refactored to use the new XML event processor architecture and the functionality that was inside the old ODTContext has been extracted in different processors.

Testing has been improved. The XML processing, including the template extraction, is now well tested and covered. The ODTCompiler area testing has been improved slightly. The new document service has been tested with the Proxeus test-api suite with success.

There are still improvement to make. For example, the formatter using LibreOffice inside the document service, which increase the complexity of the service, can be entirely externalized using projects like https://github.com/thecodingmachine/gotenberg which use the unoconv project that itself uses LibreOffice to handle its tasks. Unoconv is a ten year old project specializing in document conversion.

The handling of table row for-loop available in the old version was not migrated yet due to time limit. It is a small task as it just need to move template for loop instruction written inside table cells (as it is the only place possible if you edit the document using your document editor) outside the row. This will need to be part of an new PR.

In addition, the client has been removed and replace by curl. The API has been augmented to use addition content type that are easier to use with standard HTTP command line tools. Please refer to the updated README.

The opaque run and ui command have been removed and placed with plain java -jar command and the Dockerfile has been updated to use a multi-stage build.