CLI: refactor input path stuff

There's some code in the CLI which reads the input path and tries to work out what it means.

The problem is that we support multiple inputs in execute now:

openfn job.js
openfn workflow.yaml
openfn workflow.json
openfn my-workflow (soon)

The CLI code to manage this has evolved over time and is now just a mess.

I think I'd like a single path or inputPath. And maybe it can be an object like this:

input: {
   value: // the raw argument value
   type: 'workflow-path' | 'workflow-name` | 'expression-path' / what does this path point to?
   format?: 'yaml' | 'json' | null
}

If I can work that stuff out early, ideally without reading the file, then the logic to load and parse the actual workflow plan should get a lot easier.

This means removing expressionPath, workflowPath and planPath.

This is an annoying sort of issue, but the complexity around the current implementation, plus the amount of legacy around it, means its really blocking development right now.

I would be happy to brand this a major version if there's any risk of incompatiblity.

Start in the CLI code that handles the execute command and trace how expressionPath, workflowPath, and planPath are derived for the listed input forms. Define the unified input representation and verify that each supported input can be classified before file loading, with workflow parsing and execution still receiving the correct plan.