Its time to end the XML input antipattern

Issue:
XMLNodePtr is the (void*) of QMCPack
```C++
class ICouldDoAnything
{
MyObjectCouldBeAnything(Communicate *);
void put(void* cur);
}
```
Not only do we construct most important objects in two or more stages but this construction/initialization is driven by what amounts to void*'s.

This has to end. As void* will it evades the type system, cannot be reasoned about in the code, and allows the develop to never clearly specify the actual contents of the void*.

Going forward I propose that no new functionality be added with this pattern. At some point we have to draw a line in the sand or we'll never break free of this.

I found it relatively easy to separate input parsing, and default parameter values for the drivers into QMCDriver_input, DMCDriver_input, VMCDriver_input. If XML parsing is decoupled from object construction then objects can actually be created by constructors.

A rational basis for a valid and testable code requires clear input parameter sets expressed in native typed C++. For the developer these should be documented in doxygen comments at declaration rather than in the xml parameter tables of the manual. The manual is primarily for our users and should document the scientific and other aspects of the input from the users perspective.

Additionally the manual should not contain components under development while these components should be documented via doxygen compatible comments as they are written.

Deliverable(s):

- [ ] Specification/Directions for adding input and bringing an input dependent class to a valid state.