Big interpreter rewrite

[StachuDotNet]

Rewriting RuntimeTypes, the Interpreter, and PT2RT to:

• be generally faster
• not stack-overflow so trivially (Bug: List.map Causes Stack Overflow Error on Large Lists #5222)
• handle async and parallel processing seriously

Here are all of the wins (WIP):

• much better, structured RTEs
  • OldStringErrorTODO is gone
• better handling of RTEs, generally
  • especially dev experience (understanding what went wrong)
• async, concurrent function calls
• no easy-to-reach stack-overflows
• more tests
• super-fast builtins (without copying Dvals all over the place)
• non-recursive runtime type-checking is now complete and I can close Refactor typechecking to use value types #5071 Use package Bool.and and Bool.or #5030
• everything's faster
• hopefully fast enough for 95% of programming tasks
• partial-application works, for "applys" to both fns and lambdas
• I might add some other tiny language features? lol
• interpreter is easier to understand
• there might end up actually being a net negative in terms of LOC at the end of this?
• we're a tiny bit closer to getting tracing working in this new world
• I have some ideas on further worthwhile optimizations (will hand off to Ocean)

I might get stuck on SqlCompiler and circle back to that in another PR - not sure yet.

It'll probably be another 2 weeks until this gets merged.

This closes #5222, closes #5130, closes #5071

[StachuDotNet]

thoughts on implemented match that I wanted to record in case my current plan doesn't end up working out: https://gist.github.com/StachuDotNet/5a8923721b255ad2a91c1c6dcc3e9b8e

Edit: it worked out (really well!) but might as well keep this around.

[StachuDotNet]

Hm, why do we need this fallback case? (Source) - When is that code hit?

[StachuDotNet]

I suppose this is for the cases that we were trying to fix for -- but will the solution work if there are multiple nested lambdas? Or if a lambda is returned by a fn and used later on?

[OceanOak]

This is hit when running functions that take a lambda as an argument (e.g. List.takeWhile, List.sortByComparator, List.sortBy, List.member, List.map, etc.)

The lambda couldn't be found in the currentFrame.context which is a PackageFn, instead it is found in the Source, I wasn't sure if it was the best solution.

As for "will the solution work if there are multiple nested lambdas" it works for some functions and doesn't for others (I am encountering other errors in these cases that don't seem to be related to this issue)

[StachuDotNet]

I suppose this is a similar question - why do we need to add two entries?

[OceanOak]

the lambda is created in the Source context, but we try to apply it in the lambda that is inside a PackageFn context, here is an example of one of those functions

let map (list: List<'a>) (fn: 'a -> 'b) : List<'b> =
  (Stdlib.List.fold list [] (fun acc elem -> Stdlib.List.push_v0 acc (fn elem)))
  |> Stdlib.List.reverse

I've added this to make sure that we can find the lambda later regardless of the context in which it's being applied. Again not sure if it is the right thing to do, please let me know if you think there is a better way to do it.