[WHIT-2990] Change news article lead image payload from image to images with type

[lauraghiorghisor-tw]

Change news article lead image payload from single image to images of 'type' lead, with 'sources'

To ensure a consistent image payload across types, we are bringing the lead image payload in line with that of the other non-embeddable images, such as topical events' headers and logos, and history pages' sidebar.

The change is from sending a singular details.image to sending details.images with a type to identify the usage, and a hash of sources corresponding to the various image variants, rather than the url, high_resolution_url, medium_resolution_url we were sending prior. Since the code is scoped to config-driven document types, this change only affects news articles. History pages have been dealt with separately, and republished.

This change is accompanied by changes in publishing API, Frontend, and the metadata component (which looks for a url). All these changes will require a 2-step release: an expand to allow both payloads, then a contract after republishing. All news articles will require republishing for the change to take effect.

Note on the payload specifics:

• We have agreed with Frontend owners that, in order to keep the API consistent, and the FE code relatively simple, we will send the sources hash with all the variant keys, even for cases where the image is not truly "versioned". In the case of lead images, that's the placeholder image, which we now send replicated for all the versions ("default" kind's versions: s960, s712, s630, s465, s300, s216). This also ensures the system can expand in the future, if we then provide a versioned placeholder image. This is in line with what we do for svg images elsewhere, which only generate one asset variant.

Note on FeaturedImageData changes:

• I had to compute a sources payload for the FeaturedImageData since that's the model underlying the fallback organisation image. The publishing_api_details method sits on the Image model for regular images, so it would have made sense to put it on the "parent" model for FeaturedImageData as well, i.e. Organisation in this case. Nonetheless, there are many models using this _Data class, not just Organisation, so it is more convenient to place it straight on the FeaturedImageData for the time being.
• We can reconsider this at a later stage when more FeatureImageData usages need to be made consistent with this new payload shape, so I have made no attempts to unify concerns at this point.

Jira

[lauraghiorghisor-tw]

This is changing now, since we are always sending the caption. As far as I can tell, it makes no difference to FE, and it's now been allowed in publishing API -> alphagov/publishing-api#3924. This is consistent with the "intention" introduced by the "caption_enabled" configuration, i.e. "no caption key" should mean it is disabled, and "nil caption" should mean it is enabled but - intentionally - missing.

Previously we were using this definition instead, which allowed null, but we were always dropping the nulls in whitehall anyway by using compact on the payload, so that did not make much sense.

[lauraghiorghisor-tw]

Replicating this same url as was agreed to do, like we do with svgs as well.

[lauraghiorghisor-tw]

I don't know (yet) what we want to do with FeatureImageData so I only added sources and content_type to that method, preferring to inject type and caption here. That model does not have type yet, nor caption directly. Caption is provided on some of the models that use FeatureImageData (such as Feature), but not on Organisation, which we care about here.