[Peek] show thumbnail and fallback to icon on unsupported files

[pedrolamas]

Summary of the Pull Request

Allow Peek to retrieve the thumbnail of unsupported files and use that as icon; if a thumbnail is not available, fallback to the file icon (as it currently does).

PR Checklist

• Closes: #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

While looking through this code, I've found a couple of places where some potential memory leaks could be occurring, and I have tried to fix those as I found them.

(Specifically, when ((IShellItemImageFactory)nativeShellItem).GetImage method was called, we immediately followed it by cancellationToken.ThrowIfCancellationRequested() but never destroyed the hbitmap instance from the previous!)

Validation Steps Performed

Manual validation against a couple of .gcode, .3mf, and .unknown files

[pedrolamas]

I've converted this to draft as thumbnails transparency is not working correctly (then again, the currently in use bitmap.MakeTransparent() is not fit for purpose...)

[htcfreek]

For file/shortcut icons the transparency is not working very well too. But this is a bug since the first release of Peek.

[pedrolamas]

I've fixed the transparency issue, I think this should work with any icon/thumbnail, though I have only tested with a couple of files.

Bitmap.MakeTransparent() is NOT the correct approach here as it does not honor any potential alpha channel, it just takes the lower left pixel of the image and considers that color as transparent...

My approach is to take the current 32bit RGB bitmap, and copy the data directly to a new 32 bit ARGB bitmap (so no change to data at all, I just assume alpha is already there) and it seems to fix the transparency issue!

[stefansjfw]

Looks good. Thanks for the contribution!