Fix some problems in sets / hash tables of arrays

[bradcray]

This fixes support for sets of arrays by fixing a ==-based key comparison
and using an explicit new call to create the underlying hash table rather
than relying on default initialization (contributed by @mppf).

Specifically, we were using key == key to look for existing keys before, but
for an array type, this will generate an array of bools rather than a single bool
as we require here. So this PR pushes the test into a helper routine to compute
it, which is sufficient to get the setOfArray.chpl future working.

I then extended setOfArray.chpl to see if we could actually work with the set,
and it turned out that we couldn't due to #15929 until we applied the workaround
in that issue to ensure that the set's element type's runtime type was established
properly (thanks to @mppf).

While working on this, I added a pair of futures that demonstrate that a generic
record instantiated with an array doesn't work: genericRecordOfArray*.chpl
which seem related to:

• Problem with runtime type and default initialization #15929
• Runtime type info of domains not initialized correctly when method has in intent #13808 and/or
• handle record and class types with runtime types #11549
  but felt simpler than any futures I quickly found for those cases.

Resolves #16033.

[bradcray]

Tagging:

• @bmcdonald3 since he was looking at setOfArray.chpl earlier this week
• @mppf since he implemented ChapelHashtable.chpl
• @daviditen since he filed Set of arrays fails to compile #16033
  to see whether one of you could review.

One thought I have as I type this is whether we should also have ChapelHashtable.chpl warn if one uses an array key type today to avoid this valgrind-like unpredictable behavior (?).

[mppf]

@bradcray - we can easily get the setOfArray2.chpl example working in the same way as what we applied to map with the workaround described in #15929. Please see 8fac106 (and 2ad942c which makes some trivial formatting adjustments to the good file) and you are welcome to cherry-pick these.

[bradcray]

Aha, cool, thanks Michael. When we were talking about #15929 yesterday, I was misunderstanding that it might require users to apply the workaround proposed in that issue to their code—not that we could apply it within Set itself. Thanks for the help.

[bradcray]

OK, I think this PR is ready for review, thanks again Michael. Would one of @mppf, @daviditen, or @bmcdonald3 be willing to review it, or should I go fishing?

[bmcdonald3]

I don't mind taking a look, though, I likely won't be able to until near the end of the day

[bmcdonald3]

Looks good, only one question above. The only other comment I have is that the 2 tests seem very similar, though, no reason to not have more tests I suppose.

[bmcdonald3]

Just since we are adding this helper function, I am curious: are there any other special cases besides arrays that should be considered? (Maybe domains or something that I wouldn't know enough about to point out)

[bradcray]

I don't believe there are, though am not entirely confident myself (and am telling myself "Well, at least I made it no worse", though you're doing the correct job as a reviewer of asking).

I think we've asked whether collections like lists should return a bool or a list of bools, but today list returns bools, and I'm not able to come up with other types that don't return bool.

[bradcray]

the 2 tests seem very similar, though, no reason to not have more tests I suppose.

That's a good point and only reflects the fact that I originally thought one of them was going to have to remain a future. I'll combine them (the reason for not having more tests unnecessarily when it's trivial to combine them being testing time).