Bugfix for broken Hold dashboard searches

[jazairi]

Why these changes are being introduced:

Certain fields in the Hold dashboard, which are generated via convenience
methods and not stored in the db, were defined as Field::String. Because
Field::String is searchable by default, this caused the dashboard search
to break when it tried to query nonexistent columns.

Relevant ticket(s):

https://mitlibraries.atlassian.net/browse/ETD-304

How this addresses that need:

This changes the offending fields to Field::Text, which are not
searchable by default.

Side effects of this change:

• When I fixed this bug, I noticed that the only searchable field was
  status. I added thesis title as another searchable field, since there
  aren't many Hold model fields that are searchable in administrate.
• Notably, status is searchable only if you add a colon to the
  end of the querystring (e.g., 'active:'), due to some weirdness with
  how collection filters work in administrate.

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 increased (+0.01%) to 94.559% when pulling 5492db6 on etd-304-holds-author-names-bugfix into c6b5562 on main.

[jazairi]

Hm...locally I'm seeing 100% coverage for the Hold dashboard. Not sure why coveralls is reporting something different.

[matt-bernhardt]

Well done!

I'm also not sure why coverage isn't noted for those last two lines in the filter - it seems that they should be counted. When I run the tests locally I'm getting 95.39% coverage, rather than the 94.32% reported here.

[jazairi]

Thanks, @matt-bernhardt! I'm seeing 95.39% coverage in the latest run, so I think that coverage report ran before I wrote tests for this. In any case, I think we're good to merge.