Support augmenting module with export as namespace

[ghost]

Fixes #12106

In getTypeOfSymbol, the cases for SymbolFlags.ValueModule and SymbolFlags.Alias are separate. We're effectively treating a flags enum (where multiple flags could be set at the same time) as a regular enum (where only one member can be set). The problem is that when merging export as namespace a; with declare namespace a {}, we're merging an alias with a module.

The solution here is to resolve the alias before merging, so we're directly merging into module "a" -- this means that regular imports from the module will be affected by the augmentation too and not just namespace uses, which I think is good.

[sandersn]

how can we access a in a module?

[saschanaz]

a is a global namespace (because of declare global at line 9-14), so IMO no issue.

[sandersn]

I'm not convinced we need this ability. Does this PR need to exist for the declare module "./a" version to work?

[ghost]

Currently, if you have:
a.d.ts

export const x = 0;
export as namespace a;

b.ts

export {};
declare module "./a" {
    export const y = 0;
}

c.ts

a.y;

It will fail in c.ts. But there is no failure for import { y } from "./a"; -- the module got augmented but the namespace didn't.