Throughout the code we have quite a bit of conditionals regarding what
is a work, collection, file_set, and adminsitrative set.  This model
attempts to provide a common point to interrogate the application.

There are, at present, no refactors to use this model.

Consider how our specs and our application are inconsistent in their
declaration/configuration/stubbing.  This model should help with that.

Instead of the myriad of ways of asking about which models to use, let's
leverage a consolidated central place for information.

This is but one step in addressing other issues.

For those reading along, I removed an assertion from
`spec/features/dashboard/collection_spec.rb`.  Why?  Because the test
was creating one type of admin set, and the queries for what to show was
filtering on other kinds of admin sets.

Ultimatley creating a false assertion.

Prior to this commit, if the `update` failed, we would not have set the
`@collection_type` instance variable.  Which would mean that we'd raise
a `NoMethodError` on `NilClass` in the
`app/views/hyrax/dashboard/collections/_form_share_table.html.erb` view.

By favoring a helper method, we no longer require that the edit (nor
create) call the collection_type method.

Below is the the only view references for `@collection_type`, so the
helper_method appears to be adequate.

```shell
❯ rg "@collection_type[\. ]" app/views
app/views/hyrax/dashboard/collections/_form_share_table.html.erb
5:  <p><%= t(".#{access}.help_with_works", type_title: @collection_type.title) if @collection_type.share_applies_to_new_works? && access != 'depositors' %></p>

app/views/hyrax/admin/collection_types/_form.html.erb
22:      <% if @collection_type.admin_set? %>
```