Fix ID handling in IIIF helper methods

[dunn]

The manifest controller expects the URL to include the exhibit ID and resource ID, but the indexer has been using the ID of the resource's FeaturedImage instead. This doesn't always cause issues, because in many situations the ID of a resource's FeaturedImage and the ID of the resource itself have the same numerical representation. But those numbers can fall out of sync, and manifests will fail to load.

Meanwhile, update the iiif_service#info method to expect the ID of a FeaturedImage rather than a Resource. This brings it in line with the other RIIIFService helper methods and is how Spotlight::CarrierwaveFileResolver behaves.

[walkerwier]

The latter bug (iiif_service#info being passed a Resource id instead of a FeaturedImage id) in particular is causing us some grief at the Digital Library of Georgia. +1 to this fix.

For now we have an initializer that calls Spotlight::Resources::Upload.class_eval do ... to replace to_solr with the fixed version from this PR.

[dunn]

bumping this again

[jcoyne]

Is it possible to add a test that can demonstrate how this fix works to fix the problem?

[dunn]

@jcoyne we should be able to have a test that sets up a Resource and FeaturedImage with mismatched IDs, and runs through the logic, but I haven't been involved in Spotlight development for a while (not since I opened this PR over a year ago) and I don't currently have the time to do so.