Make conditional input parameters editable at runtime?

I think we should consider if conditional input parameters should be configurable at runtime. Its not really a right or wrong question but about prioritising how actively workflow users should be guided. In the docs conditional parameters are recommended for things such as creating a tool for selecting reference data (https://docs.galaxyproject.org/en/master/dev/schema.html#tool-inputs-conditional).

> A common use of the conditional wrapper is to select between reference data managed by the Galaxy admins (for instance via data managers ) and history files. A good example tool that demonstrates this is the Bowtie 2 wrapper.

In practice this mean that every tool which relies on reference data and is made according to the instructions will lock all workflows using it to a specific genome build. For researchers working in an environment with several animal models or microbiology this create a major usability issue.

When deciding on the issue there are two ways to prioritise when deciding if they should be editable or not.
1. Focusing on minimising the risk of users breaking workflows by selecting inappropriate options at runtime.
2. Ensure that users finds it meaningful to create Galaxy workflows for later usage by themselves or others.

If we prioritise option workflow being flexible (ie conditional parameters being editable) there are two issues:
A) Users may at runtime select to remove an output that is used later in the workflow. Yielding a message stating along the lines of "missing dataset in step X". The history will be color coded to show which step fails and error testing is identical to if a tool have failed to produce output.
B) Users may be confused if they are allowed to change input in a tool like BWA from provided reference genomes.

If we instead prioritise to lower the risk of user caused errors then we have one issue:
- It becomes less attractive for people to develop and share pipelines as their usage scope become unnecessarily narrow unless the final users are trained to edit workflows. .

Personally I work at an agricultural university with many small groups doing similar things but on different animals/microbes so for me flexibility is very important. Given the user friendly way workflows seem to fail when lacking data I do however think that the risk of issues caused by workflow failures are rather small.

No repository files, tests, or entry points are named. Start by reviewing the conditional-parameter and workflow behavior described in this issue; done would require an agreed design for runtime editing and handling removed outputs or confusing reference-data choices.

Written by the indexing model from the issue text.