[13.x] Fix incorrect image dimensions for HEIC

[zachiler]

Image::dimensions(), width() and height() read the size with getimagesizefromstring(), which misreads HEIC — it either fails outright or reports the coded/padded frame size instead of the image's true display size:

HEIC	getimagesize (current)	actual display size
iPhone photo (large)*	false → throws	3024×4032
small single-tile	138×74	137×73

_{* Large HEICs are stored as a grid of smaller tiles; getimagesize can't resolve the assembled size and returns false (php-src #20863).}

So on an ordinary iPhone upload ->width() throws today, and on smaller HEICs it silently returns the wrong number. (The conversion pipeline is fine — it goes through the driver, not getimagesize(); only the dimension inspectors are affected, which is what upload validation, aspect-ratio checks, and stored metadata rely on.)

Image::fromStorage('uploads/iphone-photo.heic')->width();
// before: ImageException "Unable to determine the dimensions of the image"
// after:  3024

$request->image('avatar')->cover(137, 73)->toHeic()->width();
// before: 138   after: 137

Fix

Follow-up to #60922, which added HEIC input/output support; dimensions() was left reading via getimagesizefromstring(). For HEIC/HEIF, dimensions are now read from the driver, which decodes the image and reports its true display size; every other format keeps its existing behaviour. HEIC requires the Imagick driver, so if the driver can't decode the image (e.g. GD) we fall back to the previous getimagesize() path — the default GD driver is unaffected.

Adds dimensions(string $contents): array to the Image\Driver contract and InterventionDriver, mirroring dominantColor() (#60932). Tests cover the driver routing, the GD fallback, and real-HEIC dimensions.