Correctly handle type promoted module symbols [#332, #375, #401]

[mrmonday]

Fixes #332
Fixes #375
Fixes #401

Problem

We get the incorrect type when analysing type promoted module symbols, causing the incorrect symbol to be used when qualifying names explicitly.

Additionally, renamed imports are removed when they match an import that's added automatically.

When an unqualified name is used in VB, the converted C# did not qualify it if it would become ambiguous.

Solution

Use the containing type of the symbol to determine the correct LHS for a MemberAccessExpression. This conveniently handles type promotion, so we can remove the special case.

If there are multiple imports of the same namespace, prefer the import with an alias, and use that for name resolution.

When converting a generic name, qualify it if possible to ensure we select the right reference.

• At least one test covering the code changed

[GrahamTheCoder]

Nice!

[mrmonday]

Looks like the other PR accidentally got merged in here... I'll clean it up and close the other PR - they touch similar code, so it's worth doing them together.

[mrmonday]

Rebased and merged everything into this single PR - I won't touch it again until I hear back from you.

I've left the clean-up commits mostly in tact, I could squash them into the relevant other commits though if you'd prefer.

[mrmonday]

Looks like this has some issues with converting things in the global namespace - I'll see if I can narrow down a test case and take a look at it tomorrow.

[GrahamTheCoder]

Yep that easily surpasses my standards for git history tidiness, no need to do any more tidying.
I see green tests, nice one! Yep global case makes sense to get in this PR too, go for it

[mrmonday]

Global case is now handled, this should be good to go.