Use simpler rule for deinit point

[mppf]

This PR updates the compiler to use simpler rules for when a variable is
dead. The expiring value analysis (proposed in #13704) did not end up
being as useful as initially expected for copy elision. As a result we
are shifting to a simpler design for when copy elision can occur -
#14874.

That leaves the expiring value analysis impacting the deinitialization
point (#11534 #11492) and the ownership transfer from non-nilable
checking (#13600). However the ownership transfer checking is not
significantly improved with expiring value analysis (it is approximately
as effective when handled by the must-alias analysis in the nil checker).
That leaves the deinit points.

Since a copy elision can cause a variable to be effectively dead in the
current scope after it occurs, there is some relationship between deinit
points and copy elision. That is why #13704 tried to address these two
together.

For example:

proc acceptsInIntent( in arg ) { ... }

proc test() {
  var x: MyRecord;
  ...
  acceptsInIntent(x); // copy elision occurs here
  // x is effectively dead in this scope
  // accesses through refs/borrows hopefully are compilation errors
  // but could be use-after-frees.
}

However since the copy elision rule is relatively simple, this PR changes
the rule for when a variable is dead to simply include the copy elision
rule. Besides that, it is based upon the simpler rule in #13704 /
#11534 (comment) .

Here is the rule as of this PR:

A variable is dead:

• after copy elision if it occurred (after the last mention is
  used to copy-initialize a variable or in intent argument)
• for the results of nested call expressions not involved in initializing
  a user variable or reference after the end of the statement
• otherwise, at the end of the scope in which it is declared

There are two important things to note about the above rule:

1. "involved in initializing a user variable or reference" includes
   through split-init
2. the above rule applies to module-scope variables (aka global
   variables) as well as local variables. For global variables

Also note that --no-early-deinit is available to make all
temps deinited end-of-block.

This PR takes the following steps to implement the change to
deinitialization points:

• add a shared helper isInitOrReturn to CallExpr.cpp; use it in
  possiblyInitsDestroyedVariable
• removes --report-expiring flag and the entire expiring value analysis
• adjusts the normalizer to leave temps in module init functions
  (instead of making them global variables) so that this can be
  determined later (after split-inits are known)
• fixes a few bugs with nil checking
• adds MarkTempsVisitor / gatherTempsDeadLastMention /
  markTempsDeadLastMention which are called from fixPrimInitsAndAddCasts
  in resolveFunction.cpp. This analyzes temp variables by how they are
  used to determine if they are used to initialize a user variable.
  Besides adding FLAG_DEAD_LAST_MENTION or FLAG_DEAD_END_OF_BLOCK,
  if the variable is in a module initialization function, it will pull
  it out into global scope.
• insertReturnTemps marks the new temps since this runs after
  MarkTempsVisitor
• adjust several tests that have use-after-frees according to the new
  rules:
  • nbody_orig_1.chpl
  • assignRecord.chpl
  • owned-class-instantiation-types-user-init.chpl
  • owned-class-instantiation-types.chpl
• (and these also which were added after checking in PR Lifetime check copy elision #15072 detected an issue with them)
  • iter-return-first-borrowed-array-element.chpl
  • owned-record-instantiation-types-user-init.chpl
  • classes/initializers/generics/inheritance/inherited.chpl

Reviewed by @benharsh - thanks!

• full local testing

[bradcray]

Noting for posterity / @mppf : This test increased the measured comm counts for the assignSlice.chpl tests in the distribution robustness suite because compiler-introduced temps at module scope were being destroyed within the measured statement rather than at the end of the program. @e-kayrakli and I verified that these comm count increases occurred on master prior to this PR if the statement in question was placed within curly brackets (forcing the destruction to occur within the measured code portion). Engin already had a branch that incorporated these new counts with some other work he was doing, so we're rolling it together rather than updating all the .goods separately.

[e-kayrakli]

Final comm count changes from this PR and from #15049 are in this commit

[mppf]

@e-kayrakli @bradcray - thanks for sorting it out