fix miscompilation with indirect tail calls (nim-works#1573)

## Summary

Fix a bug with the tail call elimination that caused target compiler
errors, or run-time errors, with the JS and C targets, in some edge
cases involving indirect tail calls.

## Details

In the MIR type IR, there are no `sink` types, meaning that
`proc(x: sink T)` and `proc(x: T)` map to the same type
representation -- the one first registered with the environment is
considered the canonical one.

The tail call elimination looked up the `PType` for the canonical type
of `.tailcall` procvals, yielding a `PType that's not the original for
the MIR type that's not the canonical one. Since the `sink` modifier is
significant for the parameter tuple type creation, this led to the
tuple having the wrong type for one of the indirect calls.

The lookup is changed to use the original instead of the canonical MIR
type, fixing the problem. A regression test reproducing the problem
is added.

Author: zerbina

compiler/mir/tailcall_elim.nim

@@ -32,7 +32,7 @@ proc getCalleeType(tree: MirTree, pos: NodePosition, env: MirEnv): PType =
   if tree[pos].kind == mnkProc:
     env[tree[pos].prc].typ
   else:
-    env.types[env.types.canonical(tree[pos].typ)]
+    env.types[tree[pos].typ].skipTypes(abstractInst)
 
 proc emitParamBlobInit(bu: var MirBuilder, tree: MirTree, call: NodePosition,
                        to: Value, g: ModuleGraph, owner: PSym,

tests/lang_callable/proc/ttailcall_wrong_parameter_tuple_type.nim

@@ -0,0 +1,19 @@
+discard """
+  description: "Regression test for internal tail call transformation bug"
+"""
+
+type Object = object
+  ## a type that uses pass-by-ref internally
+  arr: array[4, int]
+
+proc a(x: Object): Object {.tailcall.} =
+  x
+
+proc b(x: sink Object): Object {.tailcall.} =
+  x
+
+# the procedure with the non-sink parameter must be used first
+let ia = a
+let ib = b
+doAssert ia(Object(arr: [1, 2, 3, 4])).arr == [1, 2, 3, 4]
+doAssert ib(Object(arr: [1, 2, 3, 4])).arr == [1, 2, 3, 4]