Unify compile-time complex and real builds as run-time options in a single build

[williamfgc]

Is your feature request related to a problem? Please describe.

Currently QMCPACK separates real and complex functionality at compile-time. Thus, stakeholders need to create two separate executables to test, deploy and develop functionality.

Describe the solution you'd like
The long term goal is to unify these real/complex compile-time build options into a single build that can take equivalent runtime options.

Describe alternatives you've considered
Since these involve invasive changes in the entire codebase tackling compile-time conditionals e.g. #ifdef QMC_COMPLEX, there are a few steps that need to be accounted for. If possible, break down the effort into smaller tasks.

• Explore how many places need to be modified. This gist contains information extracted for #ifdef QMC_COMPLEX
• Initially replace #ifdef QMC_COMPLEX by a proper variable at the qmcapp.cpp main level and propagate through the qmcplusplus namespace. This should not be an invasive and breaking change.
• Explore more invasive changes: at the template level in QMCPACK internal functionality and CMake's build system configuration level
• Explore testing options (separate real and complex tests).
• Allow the runtime option at the top-most level (e.g. configuration xml file header)

Additional context
This issue tracks efforts and discussion related to this integration.

[prckent]

I suggest to add the runtime option next. Then adapt code starting at the lowest levels of the app that connects to it, as per the other tasks.

There are many if (QMC_COMPLEX) in the cmake test config that can be converted to dedicated complex mode tests.

[williamfgc]

@prckent @ye-luo what would be a good place for a runtime configuration option tracking real, complex, and precision (full, mixed):

• ProjectData . This is a member of QMCAppBase
• QMCState
• QMCMainState
• Other

[prckent]

These are all reasonable candidates. I would suggest ProjectData, but whatever turns out to be not too inconvenient is fine by me. There are a few too many too level objects with not sharply enough defined roles imo.

[prckent]

Also related to #4062 , which could be split when this is completed.