Follow-up on #187: The webp_uploads_content_image_mimes filter that was introduced as part of that issue controls which image formats should be preferred as replacements in the frontend content (all conditional based on whether the current attachment has a version in the given image format).

Currently the items in the filter are ordered so that:

• The most backward-compatible image format (i.e. with most widespread browser support) should come first.
• The most progressive image format (i.e. most efficient compression and file sizes) should come last.

Based on various comments (e.g. starting in #230 (comment), and also in #187 (comment)), we still need to discuss what is the most suitable expected order for the filter.

Right now, since we want to pick the most progressive format in the current implementation, we go through the array in reverse, which arguably is confusing. However, a counter-argument is that the most backward-compatible format should come first which may be "safer" and aligns it better with the webp_uploads_upload_image_mime_transforms filter for which it definitely makes more sense to have the backward-compatible format first, as it is more essential to have.

We also have to consider how this filter could be leveraged in a potential future where there is picture element support and even more progressive image formats like AVIF could be supported. At that point, we would include all of the formats in the frontend based on the order of items in this filter, and JPEG would always be the fallback.

cc @adamsilverstein @getsource