♻️ Favor existing method call over custom

[jeremyf]

This is technically a change in functionality, but one that moves
towards consistent method usage.

Prior to this commit, we were saying can_create_any_work? and
referencing the Hyrax.config.curation_concerns. Other places in the
code instead reference curation_concerns_models.

The difference is that curation_concerns_models includes FileSets and
Collections. Further, the odds that the user cannot create a Pcdm::Work
but could create a Collection or FileSet are low; meaning that this
simplification helps reduce logic foibles.

Also, as we look to Hyku, we are approaching curation concern
registration differently. The original model (e.g. GenericWork and
Image) are registered and we indicate the Valkyrie::Resources as
migrations of those model types. Meaning that
Hyrax.config.curation_concerns only has GenericWork but we want
these permissions to apply to the migrations as well.

If we don't approve this change, I'll revise Hyku's approach.

Below is a quick list of the app usages of the method:

Using rg can_create_any_work app

`app/views/hyrax/my/works/index.html.erb`

18:  <% if current_ability.can_create_any_work? %>

This logic indicates if they can see the create a new work type or not.

`

36:  <% if current_ability.can_create_any_work? && Hyrax.config.analytics? %>

Do we show the user analytics information? Again the information should
only be of things they can create. So we aren't over-exposing any
information.

app/models/concerns/hyrax/ability.rb
106:    def can_create_any_work?

`app/presenters/hyrax/homepage_presenter.rb`

Below is the impact

def display_share_button?
  (user_unregistered? && Hyrax.config.display_share_button_when_not_logged_in?) ||
    current_ability.can_create_any_work?
end

This will either show or not show a work for sharing. They would still
need to be able to read the work to see the button.

[dlpierce]

This is good. When I see curation_concerns I think of the registered work models, but not collections, filesets, etc.