[24.2] Cleanup "typical" usage of list of pairs builder.

[jmchilton]

#19248 is much more straight forward set of usability fixes for people who have messy data or data not prepped in a history for pairing. This PR cleans up the usage of the builder for users who have done everything right - they have preserved filenames with a common pattern we recognize, the datasets can be paired, and (optionally) they've selected only data they want to include in the collection. For this use case - the pair builder should just do what is needed by default and showing the pairing interface and its warning is messy and the showing the matching is... well fine... but not as clear as it could be if we weren't going to be doing pairing. For these users, I think they want to just give the collection a name and move one. This makes that a lot more clean.

If the user makes a selection that only includes pairable datasets:

In other contexts like auto-populating this from a history or a user mis-click - an additional little box shows the unmatched datasets - I think this is important for knowing what happens.

In most cases, hopefully the user can just review the table and move on. If there is an issue - there are two links to clarify what went wrong. If the problem is just with the identifiers and not the matching - we can switch the builder but hide the matching part (something added this release I think).

This component also deals with space better than the full builder and keeps the modal a reasonable size (bypassing #19249 or typical use cases).

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. use cases and screenshots above above describe how to test

License

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