feat: Species node

[rprospero]

The primary goal of this PR is to add a Species node to the graph system. This is mostly contained in src/nodes/species.h and src/gui/models/speciesModel.h. However, the following effects ensure:

1. Since species are now owned by nodes, there is no master list of species to be modeled in the DissolveModel. Therefore, the SpeciesModel class was modified from modeling a vector of species to (more closely) modeling a single species.
2. Removing the global species list broke certain keyword widgets. Since the new GUI will not be using keyword widgets, the entire folder was deleted.
3. Removing most of the old GUI widgets (including module widgets) from the compilation process. The vestigial code remains as a useful reference for porting the same logic over (e.g. we'll need a new ImportSpeciesDialog, but we can hopefully steal quite a bit of logic from the old one).

The following improvements are outside the scope of the current PR:

1. Once a species is created, we should be able to open the species back up and view its details. This should be fairly trivial (the PR worked this way before the immutable species refactor).
2. The tables for all of the various species information need headers
3. The delegates for the tables could be smarter. For example, rather than typing in the interaction function, it would be much better to select it from a list
4. We would like the species node to both accept an optional array of atom types and export its own atom types so that atom types may be shared between species.
5. Master terms are currently no accepted as their relation to the node structure is unclear.

Open Questions:

1. Should the Element combo box for the atoms display the element name or the symbol?

[RobBuchananCompPhys]

Can we expect problems if atomType_ is null? It seems like in that case, the "type" key-value pair of target[tag] will be missing, which we may well need to catch somewhere.

[rprospero]

The atomType_ is optional in the SpeciesAtom and line 499 (in the deserialise) method handles with case by checking for the "type" tag with optionalOn. That way, if the "type" tag is missing, the atomType_ is null.

[RobBuchananCompPhys]

I wonder if this may be and ideal case for a QAbstractItemModel to provide a reusable backend PeriodicTable object. It could then hold element specific attributes, such as atomic number and maybe even incorporate the datasets related to scattering length density or isotope weights. In some cases, it could be used to provide a simple drop-down like the above, but with a single line of code i.e.

model: periodicTable

[rprospero]

Honestly, I love that idea for my next PR. It also provides a very basic answer to my concern about whether to use the element name or symbol: each can be their own role and we could even allow the user to decide.

[trisyoungs]

This makes a lot of sense from the perspective of the UI, but the PeriodicTable class being proposed (which sounds like a good idea in principle) cannot have any dependence on Qt if it is to be used / accessed in the CLI code (which it frequently is).

[rprospero]

The idea is mainly about creating a wrapper model around the Elements namespace that can be accessed from the GUI. None of the CLI code would be touched, but the model could read the Elements to populate its own data before sending it to the GUI, instead of having the ElementComboBox.qml contain a duplicate copy.

Anything that might cause changes to the CLI (e.g. adding SLD information) would be done by adding it into the Elements namespace and then the GUI model simply updated to access that information.

[trisyoungs]

Looking at this I'm wondering if there is value in resurrecting my generalised table model PR (#1959)...

[trisyoungs]

I don't understand why this option is necessary?

[trisyoungs]

Actually - one big comment: For ConfigurationNode our member variable is just a Configuration, but here we have a std::shared_ptr<Species>...