[Feature]: Show DDS texture details in the Photo Info panel

[riyasy]

Problem

DDS files open and display correctly, but the Photo Info panel (I) is completely
empty for them - not just missing texture details, but no file name or size either.

ExifReader.Read() goes straight to MetadataExtractor.ImageMetadataReader, which has
no DDS parser at all. It throws, the catch returns ExifData.Empty, and the panel
renders nothing.

Reported by @lowbred who currently works around this by running Microsoft's texdiag.exe
over their texture folders from a batch file and reading the dumped .txt output.

What it should show

A DDS exposes everything needed in a fixed-layout header at the start of the file:
4-byte magic + 124-byte DDS_HEADER, plus a 20-byte DDS_HEADER_DXT10 when the pixel
format FourCC is DX10. 148 bytes at known offsets.

Summary rows:

Row	Source
Dimensions	dwWidth / dwHeight
Format	dxgiFormat, or legacy FourCC / channel masks resolved to their DXGI equivalent
Texture type	resourceDimension + miscFlag, or legacy dwCaps2
Mipmaps	dwMipMapCount, guarded by DDSD_MIPMAPCOUNT
Alpha	miscFlags2 low 3 bits (DX10); DXT2/DXT4 mean premultiplied (legacy)

Show All adds the raw spec fields (dwFlags, dwCaps, dwCaps2, ddspf.*,
dxgiFormat, arraySize, miscFlags2) so the toggle isn't a no-op on DDS.

Vocabulary must match texdiag info

Users cross-reference the panel against texdiag output they already have on disk, so
naming follows DirectXTex's DEFFMT table exactly - BC3_UNORM_SRGB, no
DXGI_FORMAT_ prefix - and dimension uses 1D / 2D / 3D / Cube.

DirectXTex resolves a legacy file's FourCC to a DXGI format on load, so DXT5 reports
as BC3_UNORM and ATI2 as BC5_UNORM. The literal FourCC stays visible under Show All.

Alpha reports Unknown for legacy files, matching texdiag. DDPF_ALPHAPIXELS is not a
usable substitute: a plain DXT5 header routinely leaves that flag clear even though BC3
always carries alpha, so trusting it reports "None" on an alpha texture.

Not using DirectXTex

The reporter suggested taking a dependency on DirectXTex. Not needed - this is a fixed
header read, not a decode. Reading it directly avoids a native dependency, a build step,
and any Native AOT risk. DirectXTex would only be warranted if FlyPhotos ever needs to
decode compressed texture formats Windows cannot handle itself, which is a separate job.

Testing

• Opening the info panel on a .dds shows file name, size, dimensions, format,
  texture type, mipmap count and alpha mode
• Format naming matches texdiag info for both DX10 and legacy FourCC files
• Show All lists the raw header fields
• A truncated or malformed DDS still shows file name and size rather than an empty
  panel, and logs rather than throws (dwSize == 124 and ddspf.dwSize == 32 are
  spec-fixed and serve as the alignment check)
• No new package or native dependency

Out of scope

Bulk/recursive scanning. The reporter's second script sweeps a folder tree hunting for
textures with mipLevels = 1; a per-file info panel does not replace that. Separate
request if wanted.

[riyasy]

@lowbred , Can you please check?

Test MSI - https://github.com/riyasy/FlyPhotos/actions/runs/31808589128/artifacts/9222325450
Or Run directly from Publish folder (unzip) - https://github.com/riyasy/FlyPhotos/actions/runs/31808589128/artifacts/9222324090