fix: prevent arbitrary file write via unsanitized SVG/MVG bitmap previews [10.16] (OC10-164)

[kw-tmueller]

Summary

Backport of #41827 to the 10.16 maintenance line.

Bitmap::getResizedPreview() sanitized SVG content before handing it to Imagick::readImageBlob(), but fell back to the original, unsanitized bytes whenever the sanitizer returned an empty string. SVG::sanitizeSVGContent() returns '' for any content libxml cannot parse, not just genuinely malformed SVG - so a malformed SVG (or any non-XML payload such as a raw MVG script) reached ImageMagick unsanitized. There, an <image xlink:href="MSL:..."> or an MVG fill 'url(...)' primitive can execute an MSL script that reads and writes arbitrary files as the web user (CVSS 8.8).

• Bitmap::getResizedPreview() no longer sanitizes-then-falls-back. It now rejects any content whose libmagic-detected media type is text/*, image/svg (with or without the +xml suffix - see note below), application/xml, or image/x-mvg before ever calling into Imagick (isDangerousToDecode()), and goes through ImagickFactory::create() so the svg:sanitize/svg:embed/svg:decode hardening options apply here too.
• SVG::sanitizeSVGContent()'s return type changes from string to ?string, returning null when the underlying sanitizer does not return a string, so callers can distinguish "could not sanitize" from "sanitized to an empty document". The SVG provider's own call site now bails out on null instead of silently passing empty content to Imagick.
• SanitizeTest is updated: SVG content fed to a Bitmap provider (PDF, Font) now must return false instead of a rendered PNG. Added regression cases for a malformed SVG with an MSL xlink:href, a raw MVG script, and a well-formed SVG - all must return false from a Bitmap provider.

Two notes specific to what surfaced while verifying this backport on PHP 7.4:

• image/x-mvg is in the deny-list because libmagic classifies a raw MVG script as image/x-mvg, not as any text/*/xml type.
• The SVG check matches by prefix (image/svg), not exact equality against image/svg+xml: PHP 7.4's bundled fileinfo build reports the identical SVG content as image/svg (no +xml), while PHP 8.3 reports image/svg+xml. An exact match would have silently passed SVG content through unblocked on this branch's PHP 7.4 target while still blocking it on master's PHP 8.3 - confirmed by running the regression suite in both a owncloudci/php:7.4 and owncloudci/php:8.3 container before settling on the prefix check.

Not in scope for this PR (flagging separately): Bitmap::getThumbnail() leaks $stream when getResizedPreview() throws - it returns at line 54 before the fclose() at line 57. That's a resource leak, not a security defect, and deserves its own focused PR.

Test plan

• make test-php-style
• make test-php-unit TEST_PHP_SUITE=tests/lib/Preview/ on owncloudci/php:7.4 - 44 tests, 8 skipped (unrelated missing Movie/Office providers), 0 failures
• Confirmed RED before the fix, GREEN after, on this branch's own PHP 7.4 target (not just carried over from the master PR)
• tests/lib/Preview/PDFTest.php (testimage.pdf) and tests/lib/Preview/BitmapTest.php (testimage.eps) still produce previews