refactor: QML GUI stack [Part 5] -> Dissolve runs in own thread + concurrent messaging and notifications

[RobBuchananCompPhys]

This work aims to run the Dissolve graph in its own thread, alleviating the GUI to be used as normal while the graph runs. The mechanisms to do this are pretty straightforward. We spin up a new thread using the QThread class, and run the graph inside it.

The trickier bit has been live monitoring of the graph's progress. This has been done via a processComplete_ member on every Node, a std::optional<bool> allowing for the resolution of three possible states: false = process started, true = process finished, and the default, uninitialised state = 'not yet run'.

This state is sampled across all nodes by their respective NodeMessages object, at 250 ms intervals, and this fundamentally determines the notification state that the user sees for each node. Running a node resets the state, and running a node that is itself a Graph resets all the progress trackers within the graph.

I've considered writing a unit test to test this behaviour, as the fact that this introduces a change to the back end Node and Graph seems to warrant a test case. However, I'm not really sure what the best way to test the mechanism is! In practice, it will throw a hard C++ runtime exception if any illogical behaviour should occur (i.e. if the progress tracker is in a true - i.e. finished - state when we start running the node, or vice versa), so every graph we run during our unit tests in a way becomes an automatic test case for this. Since we are dealing with a private member, we can't really mutate it externally to try and force the wrong behaviour.

Additionally, this system is principally of use to the UI notifications, and doesn't get called anywhere else, so I had considered wrapping the Node::started()/Node::finished() calls inside a compiler-level IF GUI etc..., but then realised that this progress might also be useful for reporting to some sort of console progress bar when running the CLI version too.