Adjust domain map implementations to no longer require pragma

[mppf]

For issue #15673.
Also for issues #15703 and #8792.

This PR:

• adjusts the domain map interface to include
  dsiElementDeinitializationComplete
• removes pragma "no auto destroy" from domain map implementations
• adds a user-facing capability to noinit arrays of POD elements

The goal of this PR is to resolve issue #15673 by adjusting the domain
map implementations to no longer require the use of a pragma "no auto destroy". Originally I was expecting to do that with a noinit
syntactic construction but it turns out that noinit is not strictly
necessary in this case since the buildArray(..., initElts=false)
pattern already covers it. Either way, the array in question has memory
allocated for elements but the elements are totally uninitialized.

In particular, to remove the need for pragma "no auto destroy", this PR
adds a deinitElts:bool field to DefaultRectangular to indicate if the
elements should be deinitialized when the array is destroyed. It adjusts
dsiElementInitializationComplete to set deinitElts to true. It adds
dsiElementDeinitializationComplete to set deinitElts to false (and
also allow similar behavior for other array types). It adjusts
dsiDestroyArr for to check this.deinitElts.

Even though noinit is not used in the distribution implementations,
this PR implements noinit for arrays of POD elements. For example,

var A:[1..10] int = noinit; // allocates space for elements but does not initialize them
for i in 1..10 {
  A[i] = i; // `=` is sufficient for initializing trivially copyable types
}

Users should also indicate when (if ever) the array's elements are
completely initialized so that the memory can be registered to support
communication. That is the subject of issue #16173.

In order to easily test no-init of arrays, this PR adds a flag
--allow-noinit-array-not-pod that will allow noinit of arrays of
non-POD elements. It uses this in several tests along with a version of a
low-level move module added to the test system. Issue #16172 discusses
the design of a user-facing low-level move module.

Reviewed by @vasslitvinov - thanks!

• full local futures testing
• primers pass with verify/valgrind and do not leak

[vasslitvinov]

The domain map interface changes and the noinit capability should be as much a highlight of the PR message as not requiring the pragma. For one, even after removing this pragma, there are still two more pragmas to remove before we can claim the ability to rely on user-facing features only.

Code changes are fine.