Adds a static name-binding pass, resolving references to static members, including static-like members such as nested classes.

In addition to resolving static members, I also expect this to be responsible for instance-member lookups in classes.

Commit-by-commit review recommended. The PR also contains a lot of drive-by fixes to the AST mapping (some of it to make tests pass, some of it to make it work on real-world projects).

Name-binding graph

Static name resolution is modelled as a graph with edges between them, using the well-known value/store/read step kinds, in addition to inheritance steps.

Cyclic Dependency on Class Hierarchy

Swift allows unqualified access to inherited members, so for example, Foo below could refer to C.Foo or A.Foo.

import A
class B : C {
    let x: Foo // <-- C.Foo or A.Foo?
}

The base classes themselves can also refer to members inherited by the outer class:

import A
class B : C {
    class D : E { // <-- inherit from C.E or A.E?
        let x: Foo; // <-- E.Foo or C.Foo or A.Foo?
    }
}

Inheritance thus depends on static name resolution, and static name resolution depends on inheritance. We resolve both in a single recursive layer.

Unqualified Lookups

An unqualified identifier gives rise to a read step from each of the scopes it could potentially be found in. In the above example, we'd get three read steps into Foo, corresponding to the three places we might find Foo.

The local name-binding pass has been augmented to support "uncertain scopes" and report back which uncertain scopes a given name access might be found it. This ensures that locally declared names can shadow lookups in outer (uncertain) scopes. For example, a locally declared Foo in the B class would block the read steps corresponding to C and A, while keeping the one from E.

The read steps currently have no priority/ranking, so there is no shadowing supported between uncertain members. There are ways to sharpen the precision a bit here, but I don't expect it to matter much -- let's only do that if we see a need for it.

Cross-file imports

This PR also adds some support for import resolution for projects with Package.swift files.

Future work

• Access levels other than public and "fully private"
• Type-extensions
• More Package.swift fidelity, such as cross-package imports
• Other build system manifests, such as xcode project files
• Support instance-member lookups