Refactor: the charge mixing code should be refactored

[WHUweiqingzhou]

Describe the Code Quality Issue

Recently, we made many modifications in charge_mixing.cpp to try various new mixing method, see #3138 . After heavy development, the code related with charge mixing is not elegant and easy-to-understand. It is a good time to re-design charge-mixing.cpp from a bird's eye view, and refactor charge-mixing.cpp.

What is the plan?

1. Polish UnitTest for Charge_Mixing, make sure the refactor is correct.
2. Charge_Mixing::set_mixing
   Current Charge_Mixing::set_mixing is called in ESolver_KS<T, Device>::Init(). Now it do two main things:

• construct mixing object.
• allocate memory for rho_mdata and nhat_mdata.
• move set_mixing after set_xc_type(), and allocate tau_mdata in set_mixing as well.
• should we spilt this function into set and allocate? Maybe yes, split into set_mixing and initialize_mixing()
• After this set, all functions in Charge_Mixing should use private variables.
• I agree this setting function can be called several times to make sure it is possible to modify mixing parameter during calculations.

3. Interface
   Charge_Mixing should only offer three interfaces:
   initialize_mixing(GlobalV)/mix_rho(Charge* chr)/mix_dmr(DensityMatrix* dm)

4. move get_drho() from Charge_Mixing to Charge.

5. Only keep one Kerker_screen_recip/inner_product_recip

6. keep old tau mixing method as mixing_tau = 1, and make a new one mixing_tau = 2.

Step 1: set_mixing()

Issue #3597
PR #3596

Step 2: init_mixing()

Issue #3599
PR #3601

Step 3: refactor inner_product()

Issue #3603
PR #3604

Step 4: refactor kerker function and polish UnitTests

Issue #3608
PR #3609

[WHUweiqingzhou]

I plan to finish this refactor after above PRs, and close this issue.