Allow batch mode to be enabled/disabled per task

[alantreadway]

I didn't see an existing feature request or mention of this when searching through issues, hoping this makes sense and we're not missing a trick.

Context
I work on a couple of projects (ag-grid, ag-charts) where we have non-trivial Nx build setups, utilising a mix of @nx/js:tsc and @nx/esbuild:esbuild executors. We also have implemented custom Nx plugins and executors to perform automated detection and build of several hundred nested projects (these are code-generators, which spit out Angular, React and Vue variants of examples; we also generate thumbnails at various resolutions and colour palettes for these, as distinct tasks).

Our custom Nx executors support batch mode, and in this mode we utilise tinypool to fan out micro-tasks.

We just upgraded to Nx 20.3.1, and through a combination of optimisations to the Nx config and executors, this took one type of these executors in batch mode from 1.7m to ~10s wallclock time - so we are super happy with where things are at utilising Nx.

The Problem
However, due to the mixing of @nx/js:tsc and @nx/esbuild:esbuild, as well as constraints on our tsconfig.json setup, we cannot enable batch mode by default. To work around this, historically we've used nx:run-commands tasks with deps on non-batchable targets to carefully issue nx run .... --batch sub-commands after non-batchable targets have been run.

This is sub-optimal from several perspectives:

• There seems to be a repeated overhead for hashing in the sub-invocations, so there is an inherent redundancy in the work being done.
• Nx cannot optimise the execution order of the tasks invoked from that sub-command within the task graph of the enclosing execution.
• This can be quite fragile, and we have to take special care on CI and in development to ensure a seamless developer experience.

Feature Request
If we could disable use of batch mode by specific troublesome targets, or alternatively force batch mode to always be used for other targets, we would be able to avoid use of nested sub-commands, and simplify our configuration.

Current Workaround(s)
We've just applied this change, which removes the old workaround (sub-commands) and patches the batchImplementation out of our problem case executors (new workaround) - in the same change we have also managed to remove use of sub-commands and other workarounds to try and reduce the fragility of that approach.