Issue #3623616 by daniel.pernold: Fetch files that are not images instead of refusing them

On 3.1.x, fetchResponse() guesses an image extension for every requested file and accepts a response only when its Content-Type starts with image/. Anything that is not an image therefore fails with Image could not be detected. - a video, a subtitle track, a PDF, or the assets of an extracted SCORM package.

This backports the 4.0.x structure: the extension list is tried for images only, any other file is fetched under the name it was actually requested with, and the image/ check stays in place for images.

Unlike 4.0.x, which accepts any 200 for the non-image case, the false-positive guard is kept: a web server that cannot serve a file may still answer 200 with an HTML error or login page, and storing that under the requested name would cache the wrong bytes. isPlausibleContentType() therefore accepts HTML only when HTML is what was requested.

Base and relation to !99. This branch starts from 3a5d2e4 on !99's branch - the iteration of #3490259 that still applies to the 3.1.6 release - so it shows that merge request's commits up to that point as well. Only the last commit belongs to this issue.

Since then !99 has moved on: it merged 4.0.x into itself and its head now carries an $is_image split of its own, so the extension half of this change already exists there. What !99 does not have is the guard above - its head returns on any 200 for a non-image. If !99 lands in its current shape, the useful remainder of this issue is that guard alone, and this merge request should be reduced to it.

Issue: #3623616