Create a separate lfd CLI tool for generating diagrams from LF programs

[lhstrh]

In order to avoid bloating lfc, diagram synthesis features should be made available using a separate CLI tool.

An easy first step would be to generate an SVG, but it might also be possible to spawn a web interface that allows interactions with the diagram in a way similar to how the VS Code does this.

One advantage of having this capability would be that we'd be able to do some primitive testing of the diagram package as part of CI.

[cmnrd]

Also see the discussion in #398.

Implementing this should make it easy to implement testing for diagrams (#802).

[lhstrh]

@a-sr wrote:

As suggested here (#398 (comment)), you can use the language server for that (since it already handles all the build weirdness). All you need is an alternative main entry class that can be used to synthesized the diagrams instead of starting a language server.
We have one in Kieler (https://github.com/kieler/semantics/blob/master/plugins/de.cau.cs.kieler.kicool.ide/src/de/cau/cs/kieler/kicool/ide/cli/KielerCompilerDiagramCLI.xtend) but it has a lot of additional functionality such as setting synthesis options (normally check boxes in the sidebar).
For a minimal prototype, the important steps are calling KlighdStandaloneSetup.initialize() and exporting the diagram with LightDiagramServices.renderOffScreen(model, format, target.path, properties). The model needs to be parsed with Xtext beforehand but I guess you already know how to do that for lfc.

Then you should be able to use the LS jar as an exporter. The only thing you have to make sure is specifying the correct entry class and put the correct platform-dependent SWT library on the class path (same as for the LS startup in VSC: https://github.com/lf-lang/vscode-lingua-franca/blob/add4b3bf15771e4096285b8043bf237ec88a2958/src/extension.ts#L37).