Allow CLI to run from source without a child process

I love to debug code - but it really doesn't work well in the CLI.

There are a few reasons for that:

1. We need to set sourceMaps: true in the tsconfig to get sourcemapping to work properly (this is easy)
2. When we run the CLI, we run yargs in the main process, but then call out to a child process to do the actual execution.

We do 2. because it allows us to default some node vm arguments (like --no-warnings and --allow-experimental-vm-modules). But there must be a better way to set this up.

The consequence of 2 is that a) we can't run directly from source (we have to build the inner process into dist/process/runner.js) and b) It's hard (impossible?) to inject a breakpoint into that inner process.

What this means is that when I run pnpm openfn workflow.json it runs from my build, not my source, and this is often confusing.

I see two possible fixes:

1. In dev mode, cut out the child process and let me run the code directly. But in prod still use the child process.
2. Don't ever user a child process and find a better way to set the required node args.

I wonder if the child process helps or hinders debugging support later in the CLI. If we spawn our own process then we can pass --node-brk or whatever the flag is to the inner process. Otherwise if the user does openfn workflow.json I don't know where or how we'll attach the debugger. We might be out of control of it by that point.

There's also a couple of closely related devx things here:

• When I run pnpm openfn ... to invoke the CLI, it runs from dist, not src. That's because of the inner process thing. I would really expect it to run straight out of source so that I don't have to rebuild all the time

Start at the CLI entry point invoked by pnpm openfn and inspect how it reaches dist/process/runner.js, including the tsconfig and Node VM arguments mentioned in the issue. Compare the proposed development-mode and no-child-process approaches; done means the CLI can run from source without rebuilding while production behavior and debugging support are addressed.