mir: add a dedicated IR for types

[zerbina]

Summary

• implement a dedicated type IR for the MIR and back-end phase
• use the new IR in parts of the C code generator
• use a new name mangling scheme for types that doesn't rely on signature hashes

Details

The idea behind introducing a dedicated type IR for the MIR and back- end phase is to:

• have a simpler and more regular IR during lowering and code generation
• decouple type lowering from code generation
• make PType solely used by sem and transf

The key ideas for the type IR are that:

• same ID (HeaderId) means same type; there are no duplicates like with PType
• transformations and code generation have easy access to the various stages of a type's representation (including the PType)
• lineage to PTypes is kept track of

The current design likely covers more ground than it ultimately needs to, but this was a deliberate choice in order to ease the transition to the new IR.

Translation

The lowering and or fixes performed by mirtypes during the translation of types intends to exactly match what was previously implemented in ccgtypes.

So that the IR is well-tested, all PTypes entering mirgen are translated to the IR representation.

Code generation

Most of the existing is still oblivious to the new type IR, with only the type emission in the C code generation. Some analysis that was previously performed on PTypes is ported to operate on MIR type descriptions.

The mangling module implements a semi-stable, reversible name mangling for types. It's necessary since not all MIR types have an originating-from PType (such as the internal payload type for seqs and strings), meaning that the sighash-based mangling cannot be used there.

AST

Associating fields with names in the C code generator is now done via the new type IR, meaning that the locId field on TSym is obsolete; it's removed.

Tests

• multiple ccodecheck test are adjusted to int now translating to a sized integer instead of NI
• due to usage of the to-MIR-type-translation, tempty_typed_expressions_issues.nim now also fails for JS

[zerbina]

It's easier to not mess with tuple equality for the moment, so I went with using sighashes to unify generic object instantiations. This restores the original behaviour of Generic[(int,)] and Generic[tuple[x: int]] translating to the same nominal C type.

[zerbina]

Okay, that fixed it. The sighashes-based approach merged types that the MIR considered to be different, since sighashes is unable to produce unique hashes for tyObject types in some cases (e.g., two object types with the same content in adjacent scopes).

Merging instantiations of generic object types is now based on the MIR representation, meaning that there can be no disagreements.

[zerbina]

Many thanks for the review, @saem.

[zerbina]

/merge

[github-actions[bot]]

Merge requested by: @zerbina

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

---

## To-Do * [x] make a separate PR with a fix for the IC-related issue * [x] ~make a separate PR with a fix for generic type equality and remove the workaround~ * [x] write a proper commit message ## Notes for Reviewers * the type IR is a requirement for much of the remaining mid-/back-end work * given the breadth and complexity of the change, it's possible that some untested behaviour ceases to work (although not intentionally) * review is likely easier by going through the commits one-by-one