Add an AMR refinement criterion useful for testing

[kidder]

Proposed changes

The new criterion drives each Element in the Domain to a target resolution and refinement level. Once it reaches the target, it will perform a given a decision that will cause the grid to oscillate between the target grid and a grid which differs by either one in resolution or refinement level.

This allows testing AMR actions in a controlled manner to make sure the mechanics of transferring data is correct.

In addition to testing, this criteria may be needed in order to drive the grid to desired initial refinement levels in order to bypass issues with Charm++

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[nilsvu]

Note here that "resolution" means number of grid points?

(Not for this PR) We've been a bit inconsistent throughout the code with this naming. Sometimes we use "number of grid points", sometimes it's "extents" (which isn't particularly clear because there's a notion of "size" attached to it), and in AMR it's "resolution" which also isn't super clear because h-refinement is also a notion of resolution. Nothing to resolve in this PR, but we should probably make this more consistent. I suggest "num points" because everyone understands what that means.

[kidder]

pushed a fixup

[kidder]

squashed

[nilsdeppe]

Why is auto-merge not enabled? The label says it should've been...

[nilsvu]

I was going to wait at least one business day before merging. Enabling auto merge would have merged this directly. Hence the label, to remind myself to merge it next business day.