Adding 2nd concern breaks Arkivo tests

[atz]

See #2999.

rspec ./spec/lib/sufia/arkivo/actor_spec.rb:58 # Sufia::Arkivo::Actor#create_work_from_item returns a GF instance
rspec ./spec/lib/sufia/arkivo/actor_spec.rb:26 # Sufia::Arkivo::Actor#create_work_from_item instantiates an actor

The basic problem is a mismatch between our Arkivo expectations mapping to a single Concern when the application has (potentially) many. Our CI will require generation of more than one concern to test other features. Currently that breaks simplistic assumptions made by Arkivo code (among others).

Reliance on Sufia.primary_work_type is fundamentally flawed. It is really just .first out of an array, initialized based on reverse-order of generation. Options are:

• remove it, using a selection flow similar to ongoing batch uploads work;
• retain it, making primary_work_type a formal designation at the model or config level;
• replace it with a specific config, e.g. arkivo_work_type; or
• replace it with something else.

Keep in mind that options 2 and 3 would involve updating the generator(s) and handling retroactive designation for installations that have already generated multiple concerns.

The problematic code is in lib/sufia/arkivo/actor.rb:

work = Sufia.primary_work_type.new

Arkivo code needs a new way to know what Concern (type) to be making, preferably on a per-object basis.

[atz]

When #3006 is resolved, the generator will respect order of generation in the (lines it inserts in the) initializer. Note: this doesn't actually resolve the problem with primary_work_type, but will make the behavior less surprising.