implement converters in sem

[metagn]

closes #381, succeeds #384

Things to do:

• Implement attaching to structural types or to . when nothing can be attached - moved to compat mode in structural converters in compat mode #401
  • Still attaches to return types as in implement converters in sigmatch #384 but this could be changed to the input type if necessary
  • Can also attach to both the return type and the input type at the same time but this would require 4 key lookups for wildcard ((a, b), (a, .), (., b), (., .))
• Compare matched converters instead of always considering them ambiguous
• commonType can instantiate the converter directly instead of calling addArgsInstConverters

Still uses the index as in #384, hopefully not a problem

[metagn]

Undrafting in case the structural type attachment isn't a blocker but will still do it in this PR if it's not merged yet

[Araq]

Structural type attachment should be behind a --compat switch as it's not part of Nimony's design. (If only we had a spec for it...)

[metagn]

Done in followup as it adds a lot to the diff

[Araq]

A NIF index file does not need to support the notion of a converter if we embrace a name mangling like <backtick>converter$typecanon. Then the exiting symbol table logic can be used. Alternatively we could treat it as the other =hooks. What do you think?

[metagn]

The main difference with the hooks is that symbols are stored instead of offsets for the corresponding procs which is only because I thought using the offsets first would make the code more complicated (wouldn't be able to make use of prog.mem etc). They could be combined either both using offsets or both using symbols (which already have mappings to offsets anyway I'm guessing)

Using a mangled name would mean that it would be a phantom symbol on top of the existing converter symbol (unless we ignore converter names) which would mean it would have to be manually added to the index anyway and it would also need to work with from import etc