Deprecate ref-maybe-const for array formal arguments

[jabraham17]

Deprecates ref-maybe-const for array formal arguments. Compiler will warn when a ref-maybe-const formal is inferred to be ref in cullOverReferences. This will not warn for compiler generated functions or outer variables (when outlining nested functions). It is written in a way that exceptions can be removed to implement other ref-maybe-const deprecations.

Implements part of the decisions for #21398 (comment)

Summary of changes

• add explicit intents (either ref or const) where needed in modules and tests
  • some functions, the body was modified to remove the need for an explicit intent (eg ref a = ... to const ref a = ...)
• tweaks compiler/passes/expandExternArrayCalls.cpp to interpret intents and use c_ptrConst.
• added temporaries for lvalue errors due to Narrow lvalue checking special case from arrays to array views #22816
  • tweaks compiler/passes/normalize.cpp to fix lvalue error with convertToExternalArray.
• rewrite bulkAdd for sparse domains to prefer codepaths that do not require sort
  • calling sort along any codepath requires the inds to be marked as ref
  • instead of taking a preserveInds boolean argument, now there is a separate bulkAddNoPreserveInds
• change uses of c_ptrTo to c_ptrToConst where applicable

New tests

• add test/deprecated/ref-maybe-const.chpl
  • also added deprecation tests for this intents, task intents, and forall intents, these are marked notest for now
• futurize test/functions/ferguson/ref-pair/ifexpr/ifexpr2-1.chpl
• add test/users/ibertolacc/void_extern_proc_array_ref.chpl

Testing

• paratest (llvm) with futures
• paratest (llvm) with gasnet
• paratest (c)
• paratest with --verify

[Reviewed by @vasslitvinov]

closes Cray/chapel-private#5218

[vasslitvinov]

For the OP / PR message:

• array argument formals --> array formal arguments [my preference]

• a ref-maybe-const formal is marked as ref:
  "is marked as" --> "is inferred to be" ?

• Please explain your addition of dsiBulkAddNoPreserveInds().
  It would also be good to add a comment in the code explaining what it does.

For the cases where you switched the default intent to const, ex. in ChapelArray.chpl or in tests like test/types/tuple/ferguson/tuple-array-concrete.chpl, I am curious why not ref and/or why an explicit intent was needed. I suspect the compiler wants to infer it as ref? why?

In test/types/tuple/ferguson/tuple-array.chpl and siblings, how well do you think your changes there preserve the intent of those tests?

[vasslitvinov]

All of the "just trailing spaces" changes are auto-fixes by my editor. I think it lightens up my PR diff, but increases the quality of some of our old code prior to the pre-merge spaces check

The space check does not apply to tests. Also, to me trailing space has no impact on the quality of code.

Excessive trailing space changes affect the PR review experience, however, and are best done in a separate PR.

[jabraham17]

For the cases where you switched the default intent to const, ex. in ChapelArray.chpl or in tests like test/types/tuple/ferguson/tuple-array-concrete.chpl, I am curious why not ref and/or why an explicit intent was needed. I suspect the compiler wants to infer it as ref? why?

In test/types/tuple/ferguson/tuple-array.chpl and siblings, how well do you think your changes there preserve the intent of those tests?

These were both changes I made with @mppf, where the rationale was we are ok forcing users to explicitly mark varargs as const. In ChapelArray, it was added to additional places other than just varargs so the intents of overloaded functions matched

[jabraham17]

@vasslitvinov I think I have implemented all of your feedback except the spaces. I will look at separating those out after I resolve the merge conflicts, but I think for this PR it may be more trouble than it is worth at this point

[bradcray]

Woohoo!