Review some typeload code

[Simn]

While looking at #4781 I've come across some confusing code in the typeloader that supports some sort of resuming for subtypes. This doesn't make much sense to me because our resolution usually picks the first thing it finds, so I started deleting some of it.

There are some failures currently but they seem very minor. I'd be interested to see if this messes up any code in the real world though.

[Simn]

I found the problem thanks to @nadako's thorough documentation of who throws what. CI is green now (I think).

My latest commit also adds a test that currently works on development, and in my opinion shouldn't. When trying to resolve C.E from within the a.b package, the compiler will find the a.b.C module, but then skip past it because it doesn't define an E type. It will then check the parent package and find a.C, which does define the E type, and so the resolution gives a.C.E.

I don't see why we should skip past that first a.b.C module here just because it doesn't define the subtype we're looking for. This seems inconsistent with how we usually resolve things.

@yuxiaomao Could you check if this change breaks anything for you guys?

[Simn]

I've added two more tests:

• With an expression-level C.E, the error message differs and says Module a.b.C does not define type C. This seems fair enough because the compiler can't possibly tell if we're talking type or field, so it assumes the latter.
• For imports we get a plain Type not found : C, which is because imports don't support partial resolution in general.

[yuxiaomao]

Checked on Shiro's codebase, it doesn't seems to break anything except one case similar to what you described: a.b.C.E tries to access C, but C is not defined in a.b.C (the filename is C and E is inside it, but class C does not exist) so it's resolved to a.C with development. After replacing C by a.C it works fine.

[Simn]

(the filename is C and E is inside it, but class C does not exist)

Could you clarify that? The way you describe it sounds like there's a/b/C.hx with a class E inside of it, in which case I'd expect that to resolve from any file inside a/b on both development and this branch.

[yuxiaomao]

There's a a/b/C.hx with class E (but no C). There's a a/b/F.hx with class F. There's a a/C.hx with class C.
class E has some use of C, e.g. class E extends SomeObj<C> var a : Array<C>, and some use of a.C e.g. @:access(a.C). In both case, C is resolve to a.C with development.
class F has also some use of C and the result is the same.
With this PR, C cannot be resolved in either E of F (Module a.b.C does not define type C) and sometimes cause some following errors, and a.C is resolved to a.C as expected.

[Simn]

Ah, so it's about a module shadowing another module which would have a type. That's a slightly different case and I didn't explicitly consider it, but to me it looks like that should fail for the same reason. Thank you for checking!