Wavefunction state serialization capability needed

A number of wavefunction parameters do not get saved during optimization (CI coeff, orbital rotations)

The current scheme updates XML nodes in `QMCCostFunctionBase::updateXmlNodes`. That function needs to get updated for every new parameter.

See discussions in #444 and #2068

We want a general solution to saving variational parameters.

**Describe the solution you'd like**

The general solution is the ability to dump the wavefunction, including the parameters and other structure.
Desirable features:
* complete state and structure so the wavefunction can be re-used easily
* As mentioned in issue 444, keeping the CI coefficients and Jastrow factors together is desirable. The easy and common path should be to reuse all the variational parameters as a set.
* Both XML and HDF formats
* XML is easy to read and modify for small cases
* HDF is necessary for scaling to large numbers of parameters
* Implementation should be distributed to classes rather than centralized as it is now

**Describe alternatives you've considered**
***Generic object serialization***
In principle, object serialization is what we want. Something like boost::serialization would do this. However, the format is opaque. I think we want to re-use the input file format for uniformity.

***Saving the list of variational parameters***
One easy approach would be to store just the variational parameters in a file. This would require two files to reload the state: the input file with the wavefunction structural information plus the file with the updated variational parameters. For the common use case, this shouldn't be too confusing. It would get a little trickier when modifying a wavefunction - the WF input file and VP file would need updated in sync.

This approach would be the fastest to implement. The more I think about it, the more appealing this solution looks (at least as an interim solution).

The code changes would be limited in scope. The list of variational parameters is centralized to the `OptVariables` list in the optimizer. This would effectively be serializing this structure to/from disk.

***Saving the entire wavefunction***
The original design had the ideal of each class reading from XML (the `put` methods). While appealing in theory, it has led to problems. XML handling gets mixed into every class. And the `put` method becomes the de-facto constructor which makes unit testing difficult.
The new approach is to separate the XML input into a separate class (the various `Input` classes).

In order to make the input and output more agnostic towards XML and HDF, we need a more independent (declarative) description of the input data. The `Input` classes seem like a natural place to add this data model, and to perform output. For example, the `OhmmsAttbuteSet` and `ParameterSet` classes would be fairly straightforward to extend to writing XML, and to handling HDF.

This approach requires defining the new model and implementing in all the needed classes before it can be used, so it will be the slowest to implement.