handle explicit generic routine instantiations in sigmatch

[metagn]

fixes #16376

The way the compiler handled generic proc instantiations in calls (like foo[int](...)) up to this point was to instantiate foo[int], create a symbol for the instantiated proc (or a symchoice for multiple procs excluding ones with mismatching generic param counts), then perform overload resolution on this symbol/symchoice. The exception to this was when the called symbol was already a symchoice node, in which case it wasn't instantiated and overloading was called directly (these lines).

This has several problems:

• Templates and macros can't create instantiated symbols, so they couldn't participate in overloaded explicit generic instantiations, causing the issue explicitly instantiated generic template fails when it has a proc overload #16376.
• Every single proc that can be instantiated with the given generic params is fully instantiated including the body. Overloaded generic procvar: useless instantiations that create type mismatch #9997 is about this but isn't fixed here since the instantiation isn't in a call.

The way overload resolution handles explicit instantiations by itself is also buggy:

• It doesn't check constraints.
• It allows only partially providing the generic parameters, which makes sense for implicit generics, but can cause ambiguity in overloading.

Here is how this PR deals with these problems:

• Overload resolution now always handles explicit generic instantiations in calls, in initCandidate, as long as the symbol resolves to a routine symbol.
• Overload resolution now checks the generic params for constraints and correct parameter count (ignoring implicit params). If these don't match, the entire overload is considered as not matching and not instantiated.
• Special error messages are added for mismatching/missing/extra generic params. This is almost all of the diff in semcall.
• Procs with matching generic parameters now instantiate only the type of the signature in overload resolution, not the proc itself, which also works for templates and macros.

Unfortunately we can't entirely remove instantiations because overload resolution can't handle some cases with uninstantiated types even though it's resolved in the binding (see the last 2 blocks in texplicitgenerics). There are also some instantiation issues with default params that #24005 didn't fix but I didn't want this to become the 3rd huge generics PR in a row so I didn't dive too deep into trying to fix them. There is still a minor instantiation fix in semtypinst though for subscripts in calls.

Additional changes:

• Overloading of [] wasn't documented properly, it somewhat is now because we need to mention the limitation that it can't be done for generic procs/types.
• Tests can now enable the new type mismatch errors with just -d:testsConciseTypeMismatch in the command.

Package PRs:

• using fork for now: combparser (partial generic instantiation)
• merged: cligen (partial generic instantiation but non-overloaded + template)
• merged: neo (trying to instantiate template with no generic param)

[metagn]

While developing this PR initially I didn't know what to do with partial generic instantiations, i.e. instantiations with missing generic parameters, before I decided to just disallow them and PR packages which had them. This was the comment I wrote about it:

There is a problem remaining of what to do with partial generic instantiations. This is in tests/generics/timplicit_and_explicit:

proc doStuff[T;Y](a: SomeInteger, b: Y): Y = discard
assert typeof(doStuff[int](100, 1.0)) is float

And a package uses it as evidenced by this error:

protobuf/src/protobuf/private/parse.nim(154, 158) template/generic instantiation of `flatMap` from here
combparser/combparser.nim(365, 37) Error: type mismatch
Expression: Nothing[(U, string)](xresult, "Unable to flat-map onto bad output", input)
  [1] xresult: Maybe[(string, string), system.string]
  [2] "Unable to flat-map onto bad output": string
  [3] input: string
  
Expected one of (first mismatch at [position]):
[1] proc Nothing[T, U, V, W](left: Maybe[U, W]; right: Maybe[V, W]; error: string;
                         input: W): Maybe[T, W]
  missing generic parameter: U
[1] proc Nothing[T, U, V](old: Maybe[U, V]): Maybe[T, V]
  missing generic parameter: U
[1] proc Nothing[T, U, V](old: Maybe[U, V]; error: string; input: V): Maybe[T, V]
  missing generic parameter: U
[1] proc Nothing[T, U](error: string; input: U): Maybe[T, U]
  missing generic parameter: U

It's supposed to emulate doing something like Nothing[(U, string), auto, auto, ...] where the number of autos is the number of remaining generic procs of each overload (you can't actually use auto like this but we can implement it), but it can crash the compiler in cases like:

proc foo[I, T](a: array[I, T]) = discard
proc foo[T](x: openarray[T]) = discard
foo[string]([1, 2, 3]) # invalid type kind for lastOrd: string

Specifically a test which does `@`[string] crashes, so we could "work around" this by not allowing partial instantiation of mArrToSeq, but you can encounter it in user code as shown above. We could also constrain I to get around it but no one will want to write array types that way and there's no good choice of constraint for all array index types. We could try to fix array types too, so that they don't match if their index type isn't an ordinal, but I think this is a general problem that can cause all sorts of issues.

The first thing I tried was only allowing non-overloaded procs to be partially instantiated, but the above cases failed. So my question is do we:

1. keep this behavior and remove the above cases (PR the package & change the test)
2. remove it for all procs regardless of being overloaded and potentially break even more code
3. allow partial instantiation somehow

The 3rd one seems the most impossible to me, the 2nd one gives us more work of PRing packages, the 1st one shouldn't cause issues but is still weird design, the instant you add an overload it gives an error. On top of 1 and 2 we can also add the auto thing.

Edit: PR'd the package anyway: PMunch/combparser#6, also the original PR that added the test just seems like it made a mistake

Edit: Also cligen, seems like a non-overloaded case:

cligen/argcvt.nim(171, 27) Error: type mismatch
  Expression: doArgParse[BiggestInt](parseBiggestInt, dst, dfl, a)
    [1] parseBiggestInt: proc (s: string): BiggestInt{.noSideEffect, gcsafe.} | proc (s: openArray[char], number: var BiggestInt): int{.raises: [ValueError], noSideEffect, gcsafe.} | proc (s: string, number: var BiggestInt, start: int): int{.raises: [ValueError], noSideEffect, gcsafe.}
    [2] dst: var int
    [3] dfl: int
    [4] a: var ArgcvtParams
  
  Expected one of (first mismatch at [position]):
  [1] template doArgParse[WideT: SomeNumber; T: SomeNumber](parse: untyped;
      dst: var T; dfl: T; a: var ArgcvtParams): bool
    missing generic parameter: T

---

One takeaway is that we can probably still support inferring generic parameters without instantiating them by writing auto in place of them, this has a trivial implementation.

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 71de7fc

Hint: mm: orc; opt: speed; options: -d:release
174002 lines; 9.050s; 655.375MiB peakmem