fix constant expressions sometimes having the wrong value

[zerbina]

Summary

Fix a critical bug with the constant-data table, which led to, in rare
cases, constant aggregate construction expressions evaluating to the
wrong value at run-time. All backends were affected.

Details

The MirNode comparison procedure of DataTable didn't take all
relevant fields into account, meaning that unequal mnkObjConstr,
mnkConstr, and mnkField were treated as equal. For example, the
comparison would result in 'true' for Obj(a: 1) and Obj(b: 1).

This problem was hidden by the hashing procedure properly considering
all relevant MirNode fields; only when there were hash or bucket
collisions did the equality problem surface. All fields are taken into
account by datatables.== now, and the used case statement is made
exhaustive in order to prevent similar issues in the future.

Since a language-level test would be rather contrived and brittle (a
hash/bucket collision is required), a unit test for the comparison
used by datatables is added.

[saem]

LoL, I was going to ask today about how to trace a few more things about mirgen. Because the mir tree being fetched on the jsgen side made no sense given that the actual mirgen for the constructor expression seemed fine. I was stuck on that bit last night. Thanks for the fix, I totally didn't think that it might be constant hashing/lookup. 😅

[saem]

/merge

[github-actions]

Merge requested by: @saem

Contents after the first section break of the PR description has been removed and preserved below:

---

Notes for Reviewers

• discovered and narrowed down by @saem in tests: organize lang spec and generic related tests #1175 (comment)
• zero being equal to negative zero for floats needs a separate PR