Implement new HPMC pair potential framework

[joaander]

Description

• Implement a new framework for multiple HPMC pair potentials: HPMCIntegrator.pair_potentials on the CPU.
• Provide LennardJones as the first example using the new framework.

The new framework allows:

1. Multiple pair potentials in a list.
2. Potentials have proper type parameters.
3. Uses ShortReal appropriately for mixed precision builds.
4. Allows users to write custom potentials that are built at compile time.
5. Names the class PairPotential to match the pair_potentials name used in the documentation.

Motivation and context

This is the first step toward implementing #1652. Future pull requests will add multi-site pair potentials (based on the CPPPotentialUnion code), anisotropic potentials (e.g. Kern-Frenkel) and provide an example component.

How has this been tested?

TODO:

• Add unit tests.
• Fix ComputeSDF.
• Fix UpdaterClusters.
• Fix UpdaterMuVT.
• Apply deprecations.
• Validate LennardJones pair potential in hoomd-validation.
• Validate ComputeSDF in hoomd-validation.

Change log

Added:

* HPMC compile time pair potential framework (CPU only). Allows potential energy in HPMC simulations without `CPPPotential`.
  * ``hoomd.hpmc.pair.LennardJones`` - Evaluate Lennard Jones energy between particles
    (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).
  * ``HPMCIntegrator.pair_potentials`` - Set a list of pair potentials to evaluate
    (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__). 
  * ``HPMCIntegrator.pair_energy`` (loggable) - Total pair energy from all pair potentials.
    (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).

Deprecated:

* ``hoomd.hpmc.pair.user.CPPPotentialBase`` 
  (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).
* ``hoomd.hpmc.pair.user.CPPPotential`` - Use a built-in potential or compile your code in a component 
  (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).
* ``hoomd.hpmc.pair.user.CPPPotentialUnion`` - Use a built-in potential or compile your code in a component
  (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).
* ``HPMCIntegrator.pair_potential`` - Use compiled potentials with ``pair_potentials`` 
  (`#1676 <https://github.com/glotzerlab/hoomd-blue/pull/1676>`__).

Changed:

* Refactored the C++ API for ``PatchEnergy`` potentials.

Checklist:

• I have reviewed the Contributor Guidelines.
• I agree with the terms of the HOOMD-blue Contributor Agreement.
• My name is on the list of contributors (sphinx-doc/credits.rst) in the pull request source branch.

[b-butler]

The PR looks good. I only have a few comments. Also, if possible we should document the expected changes between potentials in MC and MD.

[b-butler]

This PR looks ready to me.

[joaander]

Here is a performance test of hoomd-benchmarks.hpmc_pair_lj with 1000 particles on cheme-hodges:

• 4.4.1 - LLVM: 117 sweeps per second
• hpmc-pair-lj - LLVM: 88.6 sweeps per second
• hpmc-pair-lj - compiled potential: 141 sweeps per second

There is some small overhead introduced to the LLVM code path from the generalization to add multiple pair potentials together (computeOnePairEnergy). However, the compiled code path is even faster than the LLVM code path, and should be even faster after we remove LLVM. Much of the LLVM path's overhead is in the virtual function calls to getRCut and getAdditiveCutoff. The new compiled code path makes these inlined non-virtual functions to avoid this overhead.

[tcmoore3]

This is great. Just a few clarification questions, but otherwise seems ready to go.