Extract railroad generator to reusable class

[bannmann]

Here's my proposal for a Java API for railroad diagram generation. So why should RR have one? Personally, I plan to use it to create a Maven plugin for RR, but I imagine that having a Java API could make RR useful for a wide variety of other applications.

Notes

• The original generation code and logic is unchanged, only moved around and split. I verified that the output files for all three modes (regular, png, md) stay identical to master.
• The new RailroadGenerator class uses the same default settings as the CLI.
• The CLI's boolean options for choosing the output type are mapped to a single enum.
• Some setter names deviate from the previous variables in the hope of making their meaning more obvious:
  • color ➞ setBaseColor()
  • spread ➞ setColorOffset()
  • inline ➞ setInlineLiterals()
  • keep ➞ setKeepEpsilon()
• The new RailroadGenerator class is free of CLI-specific assumptions and defaults:
  • Colors are passed as java.awt.Color values instead of a hex strings.
  • The grammar is passed as a string which allows e.g. reading it directly from a UI component; existing decoding logic is kept in Railroad.
  • Exception: output still defaults to System.out even in RailroadGenerator, not only set by the CLI. The reason is that I'm not yet sure how the API for specifying outputs should look like.
    • Background: I'm toying with the idea of a working on a PR that introduces an XHTML & PNG mode which writes individual files instead of one zip. This would not involve one specific output stream, but more likely some form of "output strategy".

Caveats

• Some of the default settings documented in the new RailroadGenerator class are not implemented in that class, but in the XQuery files. This leads to some ambiguities regarding null. However, I think those are not really relevant.
• I noticed that usage() does not list the padding and strokewidth CLI options. I didn't change that as doing so is arguably not within the scope of this PR. Also, the omission may have been intentional.

---

Looking forward to reading your opinion on this! I hope you find this work acceptable - if not, please just tell me what to change.

[ggrossetie]

Here's my proposal for a Java API for railroad diagram generation. So why should RR have one? Personally, I plan to use it to create a Maven plugin for RR, but I imagine that having a Java API could make RR useful for a wide variety of other applications

I'm also interested to integrate this library in https://kroki.io/
@GuntherRademacher I would suggest to add additional maintainers to help you move this project forward. Maybe @bannmann would be interested? What do you think?

[GuntherRademacher]

Thanks for sending this PR. I have no objections. Sorry for the delay.