Clarify input behaviour

[philtweir]

What does this PR do?

The fundamental problem it solves is that, as per feedback, when a raw value is passed as an argument to a function, it should not simply be captured as a default value for that function call, but be turned into a global parameter. However, this behaviour does not make sense for raw (literal) variables inside tasks/nested tasks. In practice, this turned out to be quite a major change with a number of corner cases.

Consequently, this PR includes the following:

• subworkflows: nested tasks that are not transparent to the outside workflow, effectively having a scope and preventing literal values in nested tasks (when marked as "subworkflows" from bubbling up to the global parameters).
• parameter-naming: unnamed parameters are given names that should be predictable, but will remain distinct from each other. A potentially undesirable sideeffect is that two tasks called with the same raw variable (i.e. one not declared as a parameter) will always have separate defaults, even if they were originally the same static variable. There does not appear to be a straightforward (non-convoluted/brittle) way around this.
• the renderers can return multiple (related) workflows if subworkflows are discovered.

How to test?

Run through the documented workflows in the docs folder, and ensure they make sense with the input code.

Who can review?

@elleryames or @KamenDimitrov97

[elleryames]

The import of nested_task in workflows.md line 346 is not needed for the (shuffle) example.

[elleryames]

I understand that this PR introduces a new concept of subworkflows, and there is test for this feature in test_cwl.py. We should in addition document and give an example for this feature, perhaps in workflows.md.