Evolution: make AsciidocFX pluggable

[Ayowel]

This is a tracking issue for the evolution as I'm going to split it in several issues

Goals :

• Normalize & document interfaces
• Lower coupling between services
• Permit dynamic components loading

Target steps:

• [X] Move services to dedicated implementation folders - #518
• [X] Create services interfaces and have implementations extend them - #518
• [ ] Ongoing: Create a Service Loader & update contructors (Related to #272)
• [x] Ongoing: Add an event service to allow state change propagation without direct interactions - #521
• [ ] Cleanup parameters & fix typos in interfaces functions (setWorkigDirectory...)
• [ ] Lower internal models exposition in services interfaces (mostly : avoid JavaFX-specific/GUI object types in non-ui services functions), Create/update UI functions to handle those functionnalities
• [ ] Add dynamic class loading to add build features (POC)
• [ ] Add dynamic class loading to add build features - document interfaces
• [ ] Add loaded classes configuration support in settings
• [ ] Add injection points for plugins in UI
• [ ] Add dynamic loading support for live enable/disable ?

POC:

• [ ] Turn PDF generation support into a plugin
• [ ] Move the dynamic working directory detection (with .asciidocfx 'project' directory) to a dedicated plugin. Add local project configuration loading support.

My end goal, which would be addressed in further PRs after this, is to be able to run AsciidocFX to build PDF/HTML/... with AsciidocFX on a server without GUI so that high-level users can rely on the output they see to be reproduced on a CI platform.

Design notes: Plugins should / could

• Define their dependencies (with semver support ?)
• Be added to a loading/unloading list. Best if there is dynamic loading; Must at least have start-up configuration-defined loading
• Have user-defined configuration values
• Provide new build targets/backends
• Plug into the build pipeline
• Provide new UI options. Preferably by configuration, but a programmatic entry point may be defined
• Define new command-line options (is it do-able with the current parser ?)
• Receive internally-dispatched events

[Ayowel]

Quick heads-up. I'm still looking into ways to properly handle dynamic resources loading and though I wanted to avoid it, I think I'll have to use OSGi to get a satisfactory solution, however that implies huge refactoring & splitting the codebase in several projects.

I probably won't have the time for such an undertaking before October.

Note that by the end of these modifications, products should be uploaded to maven/ant/... repositories so that developers can specify them as dependencies.