Lindh-Malmqvist-Gagliardi Radial Grid

[wavefunction91]

Implements the LMG radial grid of this paper. Closes #11.

Requirements:

• [x] Evaluation of the radial bounds (Eqs 19 and 25)
• [x] Evaluation of the step size (Eqs 17 and 18)
• [x] Assembly into radial grid (Eqs 22 and 23)
• [ ] Modification of near-center weights according to the Gregory Formula (classical result)

[wavefunction91]

@susilehtola Per offline discussion, the latest here adds the ability to (optionally) "pre-process" base quadratures based on the existence of a particular member function. While this works, I'm not 100% convinced its the best way to do this - I'm already seeing that backing out the "correct" quadrature is yielding relative errors > epsilon (1e-15). While this probably isn't of much consequence, the fact that we can (and do) get exactly the same answers as e.g. OpenMolcas (out to machine epsilon) just by generating the correct scaled quadrature directly doesn't sit right with me.

Another option here would be, instead of adding a preprocess_base_quad function, we can pull that same trick with a generate_base_quad member function which allows the underlying RadialTraits to decide what the "right thing" is based on the requested base quadrature type. The semantics of this (at least in the case of LMG) would be that e.g. UniformTrapezoid is treated as a strong type to indicate the developer's intention and would avoid UniformTrapezoid::generate all together. From the developer's side, they don't see any of this, so the usage semantics would remain uniform regardless of the behavior under the hood. A little ugly, but it might be a more robust solution.

FWIW, this would also simplify the implementation of the DE grids as well as the Baker grid you have been implementing.