A recent Hyku feature introduced the ability to configure Bulkrax field
mappings on a per-tenant basis. It also introduced a bug that impacted
existing Hyku applications who had custom field mappings. Since the
feature fell back on Bulkrax's default field mappings if an Account
hadn't explicitly set their own, the existing field mapping
customizations in the Bulkrax initializer were ignored.

To solve that issue, as well as the question of "what if I want all my
tenants to have the same field mappings, but don't want to customize
them all by hand?", this commit introduces the idea of a set of default
field mappings at the Hyku application level.

This means that when Bulkrax looks for field mappings, it will discover
them in this order (depending on presence):

Account setting? -> Hyku defaults? -> Bulkrax defaults

There are a couple reasons why I decided to put this in the Hyku module
instead of just using Hyku's Bulkrax initializer:
1. Since they're Hyku's defaults, it makes sense to denote them as such
   semantically and conceptually
2. Since the ultimate fallback is Bulkrax's default field mappings, it
   makes sense not to alter the field mappings that Bulkrax "manages"
   with this feature
3. When adding hyku_knapsack into the mix, their often ends up being
   three separate Bulkrax config files (the knapsack's
   config/initializers/bulkrax.rb, Hyku's
   config/initializers/bulkrax.rb, and Bulkrax's lib/bulkrax.rb). This
   gets very muddy very quickly with how knapsack works technically

Ref:
- #2384

This can be used by a hyku_knapsack app initializer to override the
default Hyku application field mappings