Improve the Hyrax form API

[marrus-sh]

This PR contains three related changes aimed at polishing up the API of Hyrax::Forms::ResourceForm and related classes :⁠—

• Make all of the core Valkyrie forms inherit from Hyrax::Forms::ResourceForm. The ones which didn’t previously are Hyrax::Forms::PcdmCollectionForm and Hyrax::Forms::AdministrativeSetForm. This required splitting off some of the existing behaviours which aren’t needed for collections into a separate module, Hyrax::ContainedInWorksBehavior, which is included in Hyrax::Forms::PcdmObjectForm, Hyrax::Forms::FileSetForm, and Hyrax::Forms::ResourceBatchEditForm.

  This module is a bit long and messy, and an alternative would be to have Hyrax::Forms::PcdmObjectForm, Hyrax::Forms::FileSetForm, and Hyrax::Forms::ResourceBatchEditForm inherit from a subclass of Hyrax::Forms::ResourceForm which defined those behaviours. But the module approach seemed more flexible.

  The module could also probably be broken down into more specific parts, but it seemed a bit unnecessary given that at this time all of the forms which include it require all of those behaviours.

• Use resource_class.pcdm_collection?, etc, in Hyrax::Forms::ResourceForm.for instead of resource_class <= Hyrax::PcdmCollection. This offers more flexibility to Hyrax applications to define modules that aren’t strict subclasses of builtin Hyrax ones. The if checks are a bit complicated, because Hyrax recognizes two types of PCDM collection (AdministrativeSet and PcdmCollection), and two types of PCDM object (FileSet and application‐defined model classes). The default is now to return a generic Hyrax::Forms::ResourceForm rather than a Hyrax::Forms::PcdmObjectForm since all application‐defined models should be returning true for resource_class.pcdm_object?; if an application has defined a resource which does not inherit from Hyrax::Work, they may need to define self.pcdm_object? on their model classes.

• Change the API from Hyrax::Forms::ResourceForm.for(_) to Hyrax::Forms::ResourceForm.for(resource:_). The former is still supported, with a deprecation warning. Most places in Hyrax code take a resource argument as an explicit keyword argument, notably Hyrax::ValkyrieIndexer.for(resource:_) which is a very similar API. I have always been bothered that forms do not follow this pattern, and pre‐5.0 seems like a good time to make the switch.

[marrus-sh]

@no-reply I’ve added a new commit to split up Hyrax::ContainedInWorksBehavior. I’m not clear on which modules need Hyrax::DepositorAgreementBehavior, so I’ve just left it in everything for now. Actually, depositor is a part of Hyrax core_metadata, it just doesn’t have any form information in the schema, so every Valkyrie form needs to declare it separately. There’s probably a separate refactor involving the behaviour of depositor which could be done, but I wanted to keep the scope of this change small.