refactor: Clarify state data, input data, and resolvable data

[trisyoungs]

Some observations about node data as it stood:

The term "Serialisable" means ANYTHING...

...but they get stored in different places:

• An input parameter explicitly added with addSerialisable() -> saved to TOML.
• An option (added with addOption()) -> saved to TOML.
• Any "internal" data captured in the serialiseInternal() function -> saved to TOML.
• Data produced by the node (added with addSerialisable()) -> to be saved to the node's state ("restart") directory.
• Data saved explicitly by Node::innerSaveRestart() -> should also go to the node's state directory.

One particular point to note here is that data handled by serialiseInternal() gets written to the TOML input file, however in general I think that this internal data largely reflects calculated or produced data, and therefore it should sit with the state data.

Resolvable data...

...can exist in several places:

• Options (e.g. SpeciesSites, IsotopologueSet etc.)
• Data produced by the node (e.g. PartialSets) added with addSerialisable()

However, data resolution is only built into data marked as serialisable with addSerialisable() which envelops it within a
SerialisableClass and which has the required resolve() function. Resolvable options currently have no equivalent functionality.

Aims of this PR

• Clearly indicate state data from (input-file-) serialised data - rename addSerialisable() to addStateData().
• Clarify what is state data and have a single mechanism for serialising it - this means removal of the serialiseInternal() and innerSaveRestart() Node functions and pushing everything through addStateData().
• Introduce Parameter::resolve() in order to seamlessly handle resolution of options where necessary.
• Perform resolution of all nodes in the graph once the main deserialise() at the DissolveGraph level has completed.

Closes #2524
Closes #2373

[rprospero]

One question about tests, but everything else looks good

[rprospero]

Is there a reason that we're disabling the GUI tests?

[trisyoungs]

Good question. I believe it was because they were mostly based on old code / models and were now not working or irrelevant, or there was a breaking change caused by something else in flux at the time this PR was written. Looking at the most recent version in Rob's QML Part 4 they are enabled (even though there are very few left in the CMakeLists.txt) so I will revert this change here.

[rprospero]

I'm glad that this is going into the state instead of the input file.

[trisyoungs]

As am I!