feat: Dynamic output parameters

[RobBuchananCompPhys]

This is a fairly straightforward attempt at dynamic output parameters. It works by permitting each node to register some dynamic outputs when it has successfully run. Most likely their data will originate from the calculated results residing in some sort of container (probably a std::vector in most cases). These outputs are flagged as dynamic for later recall.

In the test parameter.cpp this behaviour is proven for standard addOutput and addPointerOutput, although I haven't tried to set it up for addOptionalPointerOutput since feels like it will be very unlikely we'd need to take dynamic outputs from a container of optional members.

The idea is to get this up and running for the immediate use case of outputting an arbitrary set of Structures from the DetectMoleculesNode, so perhaps it doesn't need to be overly-finessed at this point in time. There are certainly questions to be tackled, such as

• How long should the dynamic outputs persist in the nodes outputs_ as valid outputs? Once we have run a graph where a node accumulates some new outputs at run-time, we may well want them to persist rather than immediately clearing them away, so that they are visible when wiring new connections. There may be a requirement for a global setting 'Clean up dynamic outputs' or something to that effect
• Ensure that the QML UI can relay the appearance of newly arrived dynamic outputs to the graph (and get rid of them when they are no longer viable)

[trisyoungs]

The main thought this raised for me was "Why do we need to explicitly distinguish between a normal output and a dynamic one?". When a Node enters its process() function we are saying that it can freely create (or destroy) any data-related output parameters it has. If they are to be created, then that just happens. Once they exist in the UI, the user can freely connect to them as with any other parameter. If existing one(s) are to be destroyed, then they must ensure to explicitly detach any involved Edges. Knowing that they are "dynamic" is not really necessary. At runtime in the UI I think this makes sense.

Thinking of when a simulation get's loaded in, this is a bit trickier as we then seem to have a race condition between the node / edge data in the input file and the restart data for the node (which dictates which additional data-related outputs the node has). We can't reconstruct a graph's edges properly without having both the node data and the restart data, so the order of operation would have to be: create nodes, read node restart data (and set up additional outputs), and then connect edges. If we knew which edges connected to dynamic outputs we could defer their creation, but it doesn't change the order of operations required.