Improve support for pipeline chaining

[bentsherman]

This PR adds several features to facilitate pipeline chaining based on workflow inputs/outputs

• Allow a collection param to be loaded from a CSV / JSON / YAML file
• Print JSON representation of workflow outputs at end of run
• Allow code snippets to implicitly declare params and outputs ?
• Allow JSON params to be supplied via stdin ?

Demo project: bentsherman/pipeline-chaining-demo

The JSON output is very similar to the lineage record (lid://<workflow-run-hash>#output), so maybe we could use that instead. The lineage record has the advantage of using LIDs for files, but the JSON structure doesn't quite match the params file.

With a bit more magic we could even make the pipeline chain as simple as a Bash pipeline:

# print only output JSON to stdout when params are supplied via stdin
cat params.json | nf run fetchngs | nf run rnaseq --transcriptome [...]

But the main thing for now is the basic reading/writing of inputs/outputs, then enhanced validation with schemas and record types.

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	13b9af5
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/69194d2af58b7b00096a84cb

[bentsherman]

Everything in the above checklist has been implemented, and I'm happy with the implementation for at least the first two

The problem with the stdin params right now is that in the case of a 3-step chain, the second step blocks to wait for stdin and the third step skips the stdin because it is not "available". This leads to a lock error since the first and third run try to lock the history file.

If I skip the System.in.available() check, then the run hangs when there is actually no stdin.

I'll have to see how composable CLI tools normally handle this. I assume each tool has to initialize stdout before waiting for stdin, in order to signal to the next tool in the pipeline that stdin is coming