Energy density estimator itself

[PDoakORNL]

Please review the developer documentation
on the wiki of this project that contains help and requirements.

Proposed changes

Describe what this PR changes and why. If it closes an issue, link to it here
with a supported keyword.

What type(s) of changes does this code introduce?

Delete the items that do not apply

• Bugfix
• New feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Testing changes (e.g. new unit/integration/performance tests)
• Documentation or build script changes
• Other (please describe):

Does this introduce a breaking change?

• Yes
• No

What systems has this change been tested on?

Checklist

Update the following with a yes where the items apply. If you're unsure about any of them, don't hesitate to ask. This is
simply a reminder of what we are going to look for before merging your code.

• Yes/No. This PR is up to date with current the current state of 'develop'
• Yes/No. Code added or changed in the PR has been clang-formatted
• Yes/No. This PR adds tests to cover any new code, or to catch a bug that is being fixed
• Yes/No. Documentation has been added (if appropriate)

[ye-luo]

Please document these two functions explicitly buffer->local or local->buffer.

[ye-luo]

sumOverAll() const?

[ye-luo]

Can we use const OptionalRef<PerParticleHamiltonianLogger>?

[prckent]

General comment on functions such as sumOverAll and packData : this might not yet be in our coding guide but I would much prefer more verbose names to indicate more about what is being summed, packed etc., and as Ye put, in which direction operations are happening. Makes the code much easier to read by requiring less knowledge of the other objects and member data. Not an essential change but we do need to improve accessibility.

[PDoakORNL]

The purpose of sumOverAll is shown in test_EnergyDensityEstimator.cpp:140. I expanded the documentation somewhat.

The pack and unpack data will be used in the next PR. It seems that either the MPI communicator would have to travel over the rank scope estimators or they would need deliver either the addresses of their data or a copy of their data to the MPI communicator. I decided that for now a single packed copy with lifetime decoupled from the estimators provided the best compromise between decoupling, performance, and memory use. The documentation for that will be in the next PR since we haven't made to the enclosing scope or level in the call stack where the buffer lives.

[ye-luo]

Test this please