[Bug]: support for associative array literals with owned classes depended on violating const checks for varargs

[lydia-duncan]

Summary of Problem

Description: When #25902 gets merged, it will improve const and const ref checking for varargs. As a result, trying to create a default associative array literal with owned classes will trigger constness errors, because chpl__buildAssociativeArrayExpr takes const varargs but tries to copy the arguments (and copying an owned object modifies the object, making it not a const operation).

Consulting with Michael, it seems like we probably want chpl__buildAssociativeArrayExpr to continue taking its arguments by const for the most part. It may make sense to carve out a special case for handling owned classes, but we were concerned that would be too much to handle at the moment, so decided to futurize the test that was triggering the error for now until resolving it becomes a priority (e.g. if a user runs into it).

Is this issue currently blocking your progress? no, this can be worked around by explicitly declaring the domain for the associative array ahead of time and populating the contents of the array after its initial declaration (see HelloDataFrame-createDomFirst.chpl, which will be added by #25902

Steps to Reproduce

Associated Future Test(s): test/library/draft/DataFrames/psahabu/HelloDataFrame.chpl #25902 (modified)

Configuration Information

• Output of chpl --version: chapel 2.3 (pre-release)
• Output of $CHPL_HOME/util/printchplenv --anonymize:

CHPL_TARGET_PLATFORM: darwin
CHPL_TARGET_COMPILER: clang
CHPL_TARGET_ARCH: arm64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: bundled
CHPL_HWLOC: bundled
CHPL_RE2: bundled
CHPL_LLVM: none *
CHPL_AUX_FILESYS: none

• Back-end compiler and version, e.g. gcc --version or clang --version: N/A
• (For Cray systems only) Output of module list: N/A