Fix incongruous generics after type-checking.

[KtorZ]

• 📍 Panic when encountering unknown generics.
  This should not happen; if it does, it's an error from the type-checker. So instead of silently swallowing the error and adopting a behavior which is only sometimes right, it is better to fail loudly and investigate.

• 📍 Re-use generic id across builtin type-definitions.
  This was somehow wrong and corrected by codegen later on, but we should be re-using the same generic id across an entire definition if the variable refers to the same element.

• 📍 Change pretty-printing of unbound variable to '?'
  Until now, we would pretty-print unbound variable the same way we would pretty-print generics. This turned out to be very confusing when debugging, as they have a quite different semantic and it helps to visualize unbound types in definitions.

• 📍 Infer callee first in function call
  The current inferrence system walks expressions from "top to bottom".
  Starting from definitions higher in the source file, and down. When a
  call is encountered, we use the information known for the callee
  definition we have at the moment it is inferred.

  This causes interesting issues in the case where the callee doesn't
  have annotations and in only partially known. For example:

  pub fn list(fuzzer: Option<a>) -> Option<List<a>> {
    inner(fuzzer, [])
  }
  
  fn inner(fuzzer, xs) -> Option<List<b>> {
    when fuzzer is {
      None -> Some(xs)
      Some(x) -> Some([x, ..xs])
    }
  }
  

  In this small program, we infer list first and run into inner.
  Yet, the arguments for inner are not annotated, so since we haven't
  inferred inner yet, we will create two unbound variables.

  And naturally, we will link the type of [] to being of the same type
  as xs -- which is still unbound at this point. The return type of
  inner is given by the annotation, so all-in-all, the unification
  will work without ever having to commit to a type of [].

  It is only later, when inner is inferred, that we will generalise
  the unbound type of xs to a generic which the same as b in the
  annotation. At this point, [] is also typed with this same generic,
  which has a different id than a in list since it comes from
  another type definition.

  This is unfortunate and will cause issues down the line for the code
  generation. The problem doesn't occur when inner's arguments are
  properly annotated or, when inner is actually inferred first.

  Hence, I saw two possible avenues for fixing this problem:

  1. Detect the presence of 'uncongruous generics' in definitions after
     they've all been inferred, and raise a user error asking for more
     annotations.

  2. Infer definitions in dependency order, with definitions used in
     other inferred first.

  This commit does (2) (although it may still be a good idea to do (1)
  eventually) since it offers a much better user experience. One way to
  do (2) is to construct a dependency graph between function calls, and
  ensure perform a topological sort.

  Building such graph is, however, quite tricky as it requires walking
  through the AST while maintaining scope etc. which is more-or-less
  already what the inferrence step is doing; so it feels like double
  work.

  Thus instead, this commit tries to do a deep-first inferrence and
  "pause" inferrence of definitions when encountering a call to fully
  infer the callee first. To achieve this properly, we must ensure that
  we do not infer the same definition again, so we "remember" already
  inferred definitions in the environment now.

• 📍 Add now-necessary type-annotation to 077

• 📍 Add new acceptance test illustrating need for fn call ordering

Closes #906

[KtorZ]

Some memoization happening here, now-necessary since we might have already processed that definition. This is because:

1. There might be multiple function calls to that function
2. Simply because it's processed as part of the normal "infer_definition" loop, but has already been seen in a call from a previous definition.

[KtorZ]

Nothing is really changing in this function other than this bit. We now do pass the hydrators to the expression typer, to allow calling infer_function from within inferring an expression (e.g. a function body).

[KtorZ]

And the last actual change, we store the inferred function once we have it.

[KtorZ]

Just renamed this because it was getting confusing down the line. name is a bit too ambiguous.

[KtorZ]

Just moved this one up and added hydrators.