Enable importing types via module

[kraenhansen]

This fixes #1207 by:

1. adding two new options to CompilerBehavior:
   1. exportTypes emits "export" statements before any interface, type and a export type { Foo } for namespaces.
   2. omitDeclares prevents emitting of declare var and declare function statements which pollute the global namespace.
2. adding a new emit variation (outputting into ./module) with the two new options enabled.

I have also:

• tested the packages locally to verify that the global namespace is indeed not polluted.
• updated the baseline for tests
• updated the tests to compile the new files (as well as the files in ts5.5 which were currently not being tested).
• added examples of usage in the readme's of the deployed packages.

Merging this PR will allow users to import DOM types like this:

import type { Window } from "web/module";

function printLocation(window: Window) {
  console.log(window.location.href);
}

Ideally users would import directly (from "@types/web/module"), but this results in:

Cannot import type declaration files. Consider importing 'web/module' instead of '@types/web/module'. ts(6137)

[sandersn]

After some discussion on discord, we decided not to take this right now. @kraenhansen is planning to publish the module-wrapped code as separate package instead. My reasoning is:

The environment problem isn't restricted to the DOM types, although that's where the problem is worst. However, we need to consider the whole problem and have a whole solution ready -- which needs design work and likely needs compiler work. Unfortunately I don't think it got a lot of votes on the team for being the next thing we go work on last time we discussed that.

For this specific solution: I don't love the idea of shipping module copies of the global originals, since it doubles the size. It also requires the user to be using modules.
For the general approach: in my experience, partial solutions are duplicated with whatever real solution turns up, and are then hard to remove. I'd rather see a partial solution start out-of-band with TS' lib and lib generation. Then if it turns out to be good enough, it's easier to add it to the official pipeline than to remove it.

Given the intended usage -- directly imports and only importing types -- I think the best path forward is to publish the module-wrapped types as non-@types packages. That way people who want to try this solution can do so, and if it solves most of the cases where environments clash, we can make it official then.

[kraenhansen]

@saschanaz I wonder if you'd be open to donate the types-web package for this purpose? ☝️

[saschanaz]

Per @sandersn's post it seems the decision is maybe let people to experiment with their own packages and then later consider merging it. Having the name types-web for that purpose would be confusing to people, it might be better to make it clear it's something personal or an experiment.