Expose internal "instrumentForCoverage" option

### Command

build

### Description

E2E test runners like Cypress, in order to collect code coverage data, require the code served by the dev-server to be instrumented. I'd like the built-in builder to let me do exactly that, _considering the fact that it can._

### Describe the solution you'd like

I'd like to be able to specify `"instrumentForCoverage": true` in my `@angular/build:application` options and be done with it. I've patched my node modules to see what that would look like and it works like a charm: `@cypress/code-coverage` is generating the reports, the `node_modules` are excluded, and I'm able to use the same builder for E2E and prod builds.

In the next section I've collected some of the hoops I had to jump through to get close (but fail to attain) this level of integration. By the end of the read, I hope you'll agree with me that a built-in solution (considering it's already coded!) would be a step-up in terms of developer experience.

In the meantime, for reference, here's the quick-n-dirty patch.
```
diff --git a/node_modules/@angular/build/src/builders/application/schema.json b/node_modules/@angular/build/src/builders/application/schema.json
index 3ee8699..0b893a0 100755
--- a/node_modules/@angular/build/src/builders/application/schema.json
+++ b/node_modules/@angular/build/src/builders/application/schema.json
@@ -47,6 +47,10 @@
"type": "string",
"description": "Customize the base path for the URLs of resources in 'index.html' and component stylesheets. This option is only necessary for specific deployment scenarios, such as with Angular Elements or when utilizing different CDN locations."
},
+ "instrumentForCoverage": {
+ "type": "boolean",
+ "description": "Enables instrumentation to collect code coverage data for specific files."
+ },
"security": {
"description": "Security features to protect against XSS and other common attacks",
"type": "object",
diff --git a/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js b/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
index 675ae15..ab42aab 100755
--- a/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
+++ b/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
@@ -354,7 +354,7 @@ function createCompilerPlugin(pluginOptions, compilationOrFactory, stylesheetBun
// A string indicates untransformed output from the TS/NG compiler.
// This step is unneeded when using esbuild transpilation.
const sideEffects = await hasSideEffects(request);
- const instrumentForCoverage = pluginOptions.instrumentForCoverage?.(request);
+ const instrumentForCoverage = pluginOptions.instrumentForCoverage; //?.(request);
contents = await javascriptTransformer.transformData(request, contents, true /* skipLinker */, sideEffects, instrumentForCoverage);
// Store as the returned Uint8Array to allow caching the fully transformed code
typeScriptFileCache.set(request, contents);
```

### Describe alternatives you've considered

In my search, for Angular 20, I've found only one semi-working[1] solution that requires a 3rd-party builder (`@angular-builder/custom-webpack`) based on Webpack. That might sound like I haven't done any due diligence, when in fact I have.

- `@angular-builder/custom-esbuild` with `esbuild-plugin-istanbul` doesn't work because the `onLoad` callback of an esbuild plugin (such as the one defined by the istanbul plugin) is called only as long as no previous plugin handled the resource that's being loaded, and the `angular-compiler` handles them all.

- A possible solution could be a custom plugin that overrides the default namespace of each resource we may want to instrument (with `onResolve`), which would effectively sidestep the Angular compiler BUT force the plugin author to reimplement the compilation. Very high effort.

- A Vite plugin (rather than an esbuild one) could work, but the Angular builder is not based on Vite. `@analogjs/vite-plugin-angular` is, but it doesn't have a builder, only an executor for `@nx`, which is another can of worms. In short, the migration path isn't straightforward at all, and let's remember: this is all to add instrumentation!

- I've considered trying Angular Rspack, but [it's still experimental](https://nx.dev/technologies/angular/angular-rspack/introduction#rspack). I want my E2E tests to be as close to my production environment as they can get, and using two different builders (one for prod and one for e2e) is not an option.

- Finally, of course, the `@angular/build` package doesn't do instrumentation. Not through the builder schema anyway.

Apart from my lack of Webpack knowledge (see footnote), it appears to me that the setup I found is still not ideal. Some reasons:

1. Angular moved away from Webpack. The happy path--aka, the officially supported path--is esbuild, not Webpack.
2. Webpack is slower than esbuild in most cases. Not a big deal but I'm sure there are some peeps who'd be very impacted by that.
3. No third-party esbuild-based builder that makes use of the official devkit/extends the `@angular/build` builder will ever be able to offer a different experience. Any plugin passed to the builder will always be appended to the end of the list of plugins, *after* the angular compiler. Ergo, no `onLoad` callbacks.

[1] I say semi-working 'cause I don't know Webpack enough--but who does 😆--and didn't manage to add the instrumentation to the un-chunked code, which regrettably leads to instrumented `node_modules`

Comienza con @angular/build/src/builders/application/schema.json y @angular/build/src/tools/esbuild/angular/compiler-plugin.js, y luego sigue cómo llegan las opciones del application builder al compiler plugin. Revisa las pruebas existentes del builder y del compiler-plugin antes de hacer disponible la opción, y considera terminado el trabajo cuando la opción sea aceptada, instrumente el código de aplicación previsto y excluya node_modules de la recopilación de cobertura.

Escrito por el modelo de indexación a partir del texto del issue.