Bug: custom fields fail to display and index when imported from another exhibit

[corylown]

Description

When an exhibit with custom fields is exported and then that exported file is imported to another exhibit all the custom field information is stored in SolrDocumentSidecar and the keys of the hash get transformed from strings (as they're stored in the original exhibit) to symbols (when imported to the new exhibit). Because we're not handling the possibility that these keys could be either strings or symbols, indexing breaks and the custom field metadata does not appear in the new exhibit.

Steps to reproduce

1. Export an exhibit with custom metadata.
2. Create a new exhibit and import the exported file to this exhibit.
3. Observe that indexing fails and the custom metadata value does not appear in the edit form for items with values in that custom field.

Example of the indexing error from the Stanford Exhibits app:

Comparing the sidecar data for an exhibit created by hand via the UI (id: 9) vs. an exhibit with imported custom fields (id: 10):

 #<Spotlight::SolrDocumentSidecar:0x000000010aba5c88
  id: 9,
  exhibit_id: 5,
  public: true,
  data: {"note"=>"this is a note"}, # <======== Here's the custom field
  created_at: "2024-10-16 06:47:11.953453000 -0700",
  updated_at: "2024-10-16 06:47:52.473365000 -0700",
  document_id: "bn910qm3619",
  document_type: "SolrDocument",
  resource_id: 8,
  resource_type: nil,
  index_status:
   {:ok=>true, :timestamp=>Wed, 16 Oct 2024 06:47:12.016384000 PDT -07:00},
  tag_list: nil>,
 #<Spotlight::SolrDocumentSidecar:0x000000010aba5788
  id: 10,
  exhibit_id: 6,
  public: true,
  data: {:note=>"this is a note"}, # <======== Here's the custom field
  created_at: "2024-10-16 06:47:11.953000000 -0700",
  updated_at: "2024-10-16 06:49:05.854385000 -0700",
  document_id: "bn910qm3619",
  document_type: "SolrDocument",
  resource_id: 9,
  resource_type: nil,
  index_status:
   {:ok=>true, :timestamp=>Wed, 16 Oct 2024 06:49:05.849455000 PDT -07:00},
  tag_list: nil>]

Expected behavior

Spotlight should either always store imported hashes with string keys AND/OR it should be able to handle cases where the keys are either strings or symbols. Since it's likely data is stored with both string and symbol keys in production instances we'll probably need to be able to correctly handle either string or symbol keys in custom metadata

[dnoneill]

I will need a little time to dig, but right now this looks almost the exact same as what I was seeing in: #3197

[dnoneill]

@corylown, 91% sure this is solved with #3197