Migrate WF Collection Input Form Definition to Client Side

[jmchilton]

This is the start of #19303. This already does two important things the old form did not - the datatypes look better (the component is reused and it multiple formats can be selected - matching what is possible in the workflow definition) and the collection type component is properly validated and provides some useful help I think.

If someone wants to take up this project and do the next steps I think they would be:

• Migrate simple data inputs the same way - there should be a lot of reuse with this.
• Address the relevant comments from the PR (one about the doubly the nested JSON, one about a schema for the tool state for module types that don't use the tool form, and one about ugly hack to workaround the hack in FormDefault that ignores the first update the form issues).
• And I think... though I'm less certain... eliminate the whole build_module server interaction on each update for this component (and any workflow module/step type that doesn't use the tool form). This validates its own data - there really isn't a reason I don't think for the build_module interaction at all. The state should just be saved in the store and persisted back to the server first as part of the regular save process.

How to test the changes?

(Select all options that apply)

• This is a refactoring of components with existing test coverage. (I think we have goodish selenium coverage of this stuff).

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[ahmedhamidawan]

Is this also related to fixing/enhancing this: #19049 @jmchilton ?