…ported ECMASCript features

When optimization is enabled with the `@angular-devkit/build-angular:browser` builder, terser
is used as a second phase optimizer. The terser configuration previously set its `ecma` option
to `es2020` due to all officially supported browsers supporting the version. However, it is
possible to add browsers to the browserslist configuration that are not officially supported
that still may work but do not support es2020 syntax features. By setting the terser `ecma`
option to `es2015`, terser will not turn existing syntax into newer syntax features that might
be unsupported. Terser will also not downlevel any code based on this option.

Fixes #24347

(cherry picked from commit ef99a68)

…argeting Safari <=v15

The Angular compiler is dependent on static fields being attached to
user-defined classes. e.g. `static ecmp = defineComponent`.

These static fields sometimes rely on variables from outside of the
class. e.g. the Angular compiler generates constants for content
projection that are then accessed in the static field initializer.

Surprisingly such access to these variables may break in Safari <=v15
when a page is loaded without devtools open. The bug (already solved in
v16 of Safari)- is very subtle, hard to re-reproduce but basically
variable scope tracking is broken. This bug is triggered by additional
parenthesis in the initializer expression. See:
https://bugs.webkit.org/show_bug.cgi?id=236843.

The TypeScript compiler may generate such additional parenthesis when
it tries to adjust the `this` context when invoking methods, such as for
defining animations in the `ecmp` definition.

More details can be found here:
#24355 (comment)

To ensure Angular applications are not subject to this bug when
targeting Safari <=v15. v15 Safari, both for iOS and Mac is still part of
the default CLI browserslist with `last 2 Safari majors` (at time of
writing).

Note that it is important that the Babel plugin properly handles the
downleveling of static block-defined members. TypeScript will transform
static fields, like `static ecmp` into `static { this.ecmp = X }` when
`useDefineForClassFields = false` (which is the case for CLI apps). The
class properties plugin from Babel seems to handle this in an acceptable
way. Unlike actual static fields, Babel will not use helpers like
`defineProperty` for such extracted static blocks though. e.g.

See repro: https://gist.github.com/devversion/dec0dea26e348c509921bf62079b60be

```js
class Test {
  x = true;

  static b = true;
  static {
    this.a = true;
  }
}

// into

class X {
  constructor() {
    _defineProperty(this, "x", true);
  }
}
_defineProperty(X, "b", true);
X.a = true;
```

note that in practice TypeScript with `useDefineForClassFields = false`
will put non-static members into the constructor as normal assignments
regardless- so there would be no change by the Babel plugin.

Fixes #24355.

(cherry picked from commit 25eaaa2)

…ive more control when the readable stream is initialized

(cherry picked from commit 65f78be)

…on to latest esbuild browsers

The conversion of browserslist targets to esbuild targets has been updated to reflect additions
to esbuild. Additional browsers are now supported and the major/minor versions have been normalized.
The later of which ensures that `.0` major versions are not misinterpreted as ranges rather than
specific versions.

(cherry picked from commit a0f9db8)

…i <= v15 for esbuild

To provide a workaround for a Safari bug involving class fields and variable scoping,
the esbuild-based browser application builder will now downlevel class fields if Safari
(desktop or iOS) v15.x or earlier is within the target browsers for an application.
This is an esbuild variant of the fix for the Webpack-based builder. For more details
regarding the issue, please see: #24357

(cherry picked from commit cf2f30a)

….js value for esbuild

When using the experimental esbuild-based browser application builder, the `preserveSymlinks`
option will now default to the value of the Node.js `--preserve-symlinks` argument. This removes
the need to manually specify the option in two places if executing the build manually with Node.js
or via the `NODE_OPTIONS` environment variable. This behavior mimics that of the default Webpack-based
builder.

(cherry picked from commit 9771696)