Expose the full Amaro loader API via 'node:module'

Node.js bundles Amaro (currently v1.1.10) and uses it for the default type-stripping loader, but exposes almost none of it. After [nodejs/node#61803][] removed `--experimental-transform-types`, there is no way to run TypeScript syntax that requires transformation (enums, namespaces with runtime code, parameter properties, import aliases), and TypeScript files under `node_modules` are always rejected with `ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING`. The escape hatch we document today is `npm install amaro` plus `--import=amaro/transform` — installing from npm the exact same code that already ships inside the Node.js binary. This proposal exposes the bundled Amaro loader as a small, runtime-configurable API on `node:module`, so that full TypeScript support, including files inside `node_modules`, is 1–3 lines of code away, with no flags and no dependencies: ```mjs // enable-ts.mjs import { configureTypeScript } from 'node:module'; configureTypeScript({ mode: 'transform', nodeModules: true }); ``` ```console $ node --import ./enable-ts.mjs app.ts ``` ## Motivation 1. **The capability already ships in the binary.** `deps/amaro/dist/index.js` exports `transformSync(source, { mode: 'transform', sourceMap, filename })`, and `deps/amaro` even contains the ready-made `transform-loader`. Core only wires up `mode: 'strip-only'`. Telling users to install `amaro` from npm to unlock functionality that is compiled into their `node` executable is hard to justify, adds a supply-chain surface, and risks version skew between the bundled SWC and the npm one. 2. **The removal of `--experimental-transform-types` left a real gap.** The flag was removed ([nodejs/node#61803][]) rather than stabilized, which was the right call for a *default*: erasable-only syntax is the direction the TypeScript ecosystem is heading (`erasableSyntaxOnly`). But existing codebases full of enums and runtime namespaces can no longer run on Node.js directly at all. An explicit, i…