This drops global declarations from this file (as they will be limited to `zone.ts`. It also deletes the `/** @internal */` annotation on `AmbientZone` which is no longer necessary since it isn't in the `declare global` and deletes the global Zone declaration which is also unnecessary.

PR Close #53443

#53443)

This allows the types to be directly imported when used.

PR Close #53443

The IIFE will be removed shortly to support exporting symbols inside it.

PR Close #53443

This removes a name collision on `Zone` with the interface. Otherwise putting the `interface Zone {}` and `class Zone {}` in the same scope when the IIFE is removed will cause a conflict.

PR Close #53443

…oking it as an IIFE (#53443)

This removes the top-level side effects from this file. Indenting is left as-is to minimize changes.

PR Close #53443

All its content has been copied to `zone-impl.ts`, so this file will become a wrapper for those symbols.

PR Close #53443

…zone.ts` (#53443)

Global state is to be managed in `zone.ts` rather than `zone-impl.ts`.

PR Close #53443

…3443)

Now that we have real ES modules, there's no need for the prefix convention.

PR Close #53443

These are all the symbols originally under `declare global {}` with the same names. Unfortunatley TypeScript treats a `declare global {}` scope as the parent scope, so we need to import with a different name than the global, meaning everything gets an `_` prefix.

PR Close #53443

)

`zone.ts` contains the global variable definition and is the appropriate place for an error side effect when Zone is initialized twice.

PR Close #53443

…zone.ts` (#53443)

This helps consolidate globals into a single declaration in a single file.

PR Close #53443

…ns (#53443)

This removes top-level side effects from each of these files and drops the dependency on global `Zone`, instead allowing it to be provided to each patch as a parameter.

Most of these are pure mechanical transformations. A couple notable files which were somewhat unique:

* `async-test.ts`, `fake-async-test.ts`, and `wtf.ts` had unique IIFE usage and patch `Zone` itself. This removes the IIFE and exports the function instead.
* `jest.ts` and `jasmine.ts` have a unique `jest` global usage which needs to be declared.

PR Close #53443

… function. (#53443)

This particular is slightly different from the others because it does not have a hard dependency on `Zone`. It doesn't actually use `Zone` directly during the patch because the patch just sets a `legacyPatch` global. To maintain consistency, this continues to use global `Zone` and does _not_ accept `Zone` as a parameter. While it's using a global in an inconvenient way, this isn't a problem right now because it doesn't cause or require a dependency on a top-level side effect.

PR Close #53443

… function (#53443)

This drop the top-level side effects in `zone.ts` and allows the initialization to be reused across the various entry points in the package.

PR Close #53443

…3443)

Since each patch no longer contains top-level side effects, each bundled entry point needs to import and call its associated patch. For the most part this just means that each entry point imports the associated patch and invokes it at the top-level scope.

Note that many of these entry points did not actually have a dependency on `Zone` and had no guarantee that it was loaded prior to execution. To maintain consistency, the missing dependencies on `Zone` are left as-is. They will use the global instance of `Zone` and if users fail to load it prior to importing a specific patch, then the patch will fail just as it did previously.

PR Close #53443

This removes a dependency on a top-level side effect of global Zone initialization.

PR Close #53443

While `ProxyZoneSpec` was implicitly global previously, it does not need to be exposed in a `declare global {}` block. This is because classic scripts in TypeScript are only implicitly global within the same compilation. `ProxyZoneSpec` was not exposed in the existing `.d.ts` files shipped with the `zone.js` package. Within google3, this is also a separate compilation and was not accessible. As a result, `ProxyZoneSpec` was always private and we do not need a global to maintain compatibility.

PR Close #53443

…3443)

While `TaskTrackingZoneSpec` was implicitly global previously, it does not need to be exposed in a `declare global {}` block. This is because classic scripts in TypeScript are only implicitly global within the same compilation. `TaskTrackingZoneSpec` was not exposed in the existing `.d.ts` files shipped with the `zone.js` package. Within google3, this is also a separate compilation and was not accessible. As a result, `TaskTrackingZoneSpec` was always private and we do not need a global to maintain compatibility.

PR Close #53443