Only display unassigned files by default

[JPrevost]

Why are these changes being introduced:

• The list of files can be quite large in some cases
• Scrolling through files that have already been processed can be
  annoying and inefficeint
• Most of the time, it is not useful to see the already assigned files

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/ETD-366

How does this address that need:

• Enables conditional display of the already assigned files during
  the Transfer processing workflow
• The default is to not display assigned files

Document any side effects to this change:

• Choosing to display assigned files should be sticking throughout the
  processing of that Transfer but would need to be reapplied when
  changing to a different Transfer. Being sticky beyond what we have
  implemented here would require using a session or local storage which
  didn't seem necessary at this time but wouldn't be difficult to
  implemente in the future if that is the desired behavior.
• The display of the <li> elements had to be adjusted slightly to
  prevent blank <li>s being displayed for the files we are skipping.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

NO

[coveralls]

Coverage remained the same at 94.755% when pulling f2f976d on etd-366-shrinky-list into 25e8948 on main.

[matt-bernhardt]

Huh... coming into this ticket I was expecting it to go one of two ways (filter the list via javascript without a page load, or split the record loading in the controller). This is going down a third path, but I think I see the motivation. Interesting. This both allows for testing of the feature (harder with a javascript implementation), and doesn't grow the controller as much as I thought it might (with multiple record loading paths).

The tests pass, I see the feature working, so