[only for discuss] Refactor: introduce explicit contexts for module_hs

[goodchong]

I'm considering how to break down global variables like globalc, globalv, param, and input into a series of struct variables.

This is an experimental implementation request (PR) for community discussion.

The principles and ideas behind this PR are roughly as follows:

1. Don't modify the existing global variable system initially; instead, create a separate system to facilitate phased development. This new variable system will break down the original input variables into a series of smaller structs, categorized by type. These smaller structs are the smallest unit for passing variables between modules.

2. Pilot the new system in the module hs to demonstrate its effectiveness.

3. Pass the decomposed smaller struct variables as parameters to the module hs, replacing the global variables in the module hs.

4. Don't create separate options/context within the module hs, as I believe copying variables multiple times is a poor implementation approach.

What's changed?

• Add a standalone ModuleContext data model and C++11 builder that projects the existing Input_para, System_para, GlobalV, EXX, and restart state without replacing the legacy sources.
• Make Driver the assembly root and freeze SimulationContext after derived runtime initialization.
• Pass only focused context slices through ESolver, MD, relax, and H/S output call chains.
• Remove direct global-state reads from source/source_io/module_hs and update all repository call sites to the new interfaces.
• Preserve existing INPUT parsing, defaults, output file names, formats, ordering, and numerical behavior.

Governance Notes

• INPUT/docs changes: none; no INPUT parameter, parser, default, validation, or user-facing behavior changed.
• Core module impact: ESolver/MD/relax runner signatures now receive an immutable assembled context, while module_hs receives only the small slices it consumes. The ksdft_lr_lcao special path now runs after context finalization.
• Remaining legacy global access is confined to the builder/adapters and unmigrated code; no new global instance or service locator was introduced.
• Exceptions requested: none.