feat: support type-only/uninstantiated namespaces

[acutmore]

This PR adds support for type-only/uninstantiated namespaces. i.e. namespaces that only use type and interface.

export class C {}

export namespace C {
  export type T = string;
}

Before: Error. only declare namespace ... was allowed ❌

Now: Ok. namespace declaration erased ✅

---

The following cases remain unchanged:

// Instantiated namespace errors
namespace A { export let x = 1 }                // error
namespace B { ; }                               // error

// Ambient namespace is erased
declare namespace C { export let x = 1 }        // ok erased
declare module    D { export let x = 1 }        // ok erased

// `module`-keyword errors
module E { export let x = 1 }                   // error
module F { export type x = number }             // error

Testing

Unit tests for both supported cases and unsupported cases (errors) have been added.

Context

This addition was motivated by --erasableSyntaxOnly and the recognition that in today's TypeScript, the only way to augment a class with types after the initial declaration is via namespaces. Whilst that use case can be solved using declare namespace that comes with a hazard. The combination of --erasableSyntaxOnly checks and transforming uninstantiated namespaces provides a safer option.

Thanks to @jakebailey for bringing this to our attention microsoft/TypeScript#61011 (comment)

[magic-akari]

Our one-pass design (SWC), while optimal for speed, inherently defers complex symbol resolution — a trade-off that aligns with tsc's isolatedModules for explicit import type syntax in ESM interactions.

However, this architecture faces new challenges as we now support namespaces. Unlike ESM's enforced type/value distinction, namespace imports/exports (e.g., My.Internal.Types) require non-trivial static analysis to resolve ambiguities:

• Prior Approach: Namespaces were ignored, sidestepping the need for deep resolution.
• Current Need: Determining if Types is a value or type within namespaces demands preliminary metadata collection, contradicting our single-scan constraint.

Adopting TypeScript syntax that mirrors ESM's explicitness — such as:

import type Types = My.Internal.Types;  // namespace type binding

— would extend the same design principle to namespaces. By declaring intent upfront, the compiler could resolve symbols in a single pass without heuristic fallbacks, bridging the gap between ESM rigor and namespace flexibility.

[acutmore]

HI @magic-akari

ts-blank-space is the same, there is no symbol resolution.

I should have made the test case clearer. All ImportEqual statements are OK and do not count as an instantiated namespace.

For example: https://bloomberg.github.io/ts-blank-space/play/#eyJ0c3giOmZhbHNlLCJ0ZXh0IjoibmFtZXNwYWNlIE4xIHtcbiAgICBleHBvcnQgbGV0IHZhbHVlID0gMTtcbn1cblxuZXhwb3J0IG5hbWVzcGFjZSBOMiB7XG4gICAgaW1wb3J0IGkgPSBOMS52YWx1ZTtcbiAgICBleHBvcnQgdHlwZSBUID0gdHlwZW9mIGk7XG59XG4ifQ

https://www.typescriptlang.org/play/?#code/HYQwtgpgzgDiDGEAEBJYUAuJgYJYgwgBMkBvAKCSqQgA8YB7AJwyQBsJWA3ENgV2QBeJAEYA3OQC+5cnUYskoSLATIAqsFzosOfIRIVqSXGHnckwtJmx4CxAHQ9+ECUbnNWGAJ4xkAFQskb18GADMkLglpIA

[acutmore]

Opened #38 to add more test cases.