New feature - run configurations

[sillydan1]

This PR adds a new feature: Run configurations. Very much inspired by the jetbrains IDEs' feature of the same name. You can now run any program from inside the IDE.

It would be much appreciated if I could get some help with the UI/UX design specifically the run configurations-editor is not very pretty and could use some love

Screen.Recording.2022-11-05.at.18.44.59.mov

Features

• Add run configurations: run any kind of program from inside H-UPPAAL

Fixes / Minor improvements

• Cleanup in classes that affect the run configurations feature
• Buttons now have a subtle hover-effect, enhancing the user experience a bit
• Updated gson to version 2.10 (notably, records can now be serialized/deserialized!)
• add version information into the statusbar

Missing Tasks

• Clicking "stop" whilst a run configuration is running should SIGTERM it, right now it just adds another thread
• Bump version number
• Run configurations should be able to provide additional environment variables to the command
• Test on MacOS
• Test on GNU/Linux
• Test on Windows

For the moment run configurations will be stored in preferences. I personally think they should be saved in the project files instead. However, to keep the scope reasonable I have omitted this from this PR.

The output of a command will currently be put in the "Warnings" tab. This is not ideal, however I am also working on a complete rewrite of the CodeAnalysis/Logging system (I will make sure to keep it backwards compatible to ensure that the uppaal integration still works) so unless it's a really big issue (or easy to fix) I have also considered that "out-of-scope" for this PR.

[Nielswps]

What is the intended use case for this feature?
I personally would just use a terminal to run executables and wonder if this is outside the scope of the application. It is probably just because I do not have a lot of experience using the system, but an example of a use case would be nice

[sillydan1]

What is the intended use case for this feature?
I personally would just use a terminal to run executables and wonder if this is outside the scope of the application. It is probably just because I do not have a lot of experience using the system, but an example of a use case would be nice

The specific use-case would be that at our company we use a custom model compiler, debugger and a bunch of other utility tools (upload-scripts, unit-test runners etc.). Not all of these are implemented in java, so a direct java interface would be impractical (I would also argue that would be out of scope for the editor)

Model-designers are not necessarily developers themselves and they don't necessarily know how to use a terminal (especially on windows, this can be a problem) so this feature provides a generic way to integrate our tools, and makes it much easier to iterate on a model and get feedback from our tools.

In combination with the logging system refactor tools can provide clickable links to exactly where an error has occurred - providing a seamless developer experience.

From the perspective of running a model-checker on your models, I would argue that it is more seamless to simply push a button in the editor and click on the problem, than to tab out, write the command, and interpret the standard-output manually to find the culprit component/syntax error/whatever went wrong.

For this feature to be truly complete, run-configurations would have to be saved per-project and should be "shareable" (through git) rather than saved in the global preferences. However, I dont have much insight in the model-representation part of the codebase (right now, I'm slowly learning the architecture) so I haven't implemented that yet.

I can arrange a meeting about a use-case demonstration, if you'd like?

[Nielswps]

Looks good 👍 Thanks for clarifying the use case, I think it makes a lot of sense