Rework scope in compiler

[depombo]

Multiple inheritance does feel like potentially the right approach for interface functions, because the calling site may have the definition of a type and usable functions within it that aren't in the original function's scope, so it should check that scope for its needs first, and then check its original scope if not found in the callsite scope. The problem is actually how it was tacked on behavior from the interpreter days rather than baked in. It was originally structured for the interpreter where these things could be created dynamically, and then we bolted static behavior on afterwards.

Taking that merged scope view and putting the resulting artifacts back into the calling scope (but you can't just attach the function scope as a secondary parent scope because there can be weird cycles as you saw). Updating microstatementInlining or something else to automatically construct the correct scope and do the work to move the realized types to the correct real scope seems like the proper solution here, and having scope attached only to the function level instead of statement level, to make this less confusing. There might be a better solution though

Surfaced because user defined types were not working for Trees. This was an issue with how interface types are replaced with real types, and causes some of the relevant definition to live in one scope versus another. The interfaceMap passes the type through, but not the rest of the context it needs. Patched by https://github.com/alantech/alan/pull/337