feat: reduce image crate features to PNG/JPEG baseline

[thxtech]

Split add_thumbnails so it only enables PNG and JPEG by default. Add image_gif, image_webp, and image_tiff feature flags for opt-in support of additional thumbnail formats.

Partially addresses #1593

Changes in this pull request

• add_thumbnails now only enables PNG/JPEG decoding and encoding
• Added image_gif, image_webp, image_tiff feature flags that each enable the corresponding image crate feature
• Gated ThumbnailFormat enum variants (Gif, WebP, Tiff) and related match arms with #[cfg(feature = "...")]
• Updated feature documentation in lib.rs

Checklist

• This PR represents a single feature, fix, or change.
• All applicable changes have been documented.
• Any TO DO items (or similar) have been entered as GitHub issues and the link to that issue has been included in a comment.

[thxtech]

Questions for reviewers

1. Should WebP be included in the default baseline? The issue and comments suggest WebP could be a good default due to its small size and wide web support.
2. Should we add a warning log when a thumbnail is silently skipped due to a missing feature flag? With ignore_errors = true (the default), users won't get any indication that thumbnails are not being generated.
3. The issue also mentions WASM support. Should that be handled in this PR or a separate one?

[gpeacock]

What is the motivation for this? Do you want to reduce code size? Would it make sense to tie this thumbnail support with the support for the assoiciated asset types?

[thxtech]

@gpeacock
The main motivation for this PR is to reduce the default binary size and dependency surface of thumbnail support.

In local release builds, enabling the extra thumbnail codecs increased the size of the c2pa rlib by about 2.3 MiB (roughly 46.4 MB -> 48.7 MB). I also checked an end-user binary (c2patool), and this change reduced the release binary size by about 1.3 MiB across the PR.

Based on that, I kept PNG/JPEG in the baseline and made GIF/WebP/TIFF opt-in, so consumers who do not need those codecs do not pay that cost by default.

I treated thumbnail codec support separately from asset-type support because my goal here was to make the extra codec cost opt-in at the thumbnail layer. That said, I agree this is also a feature-boundary question, and if tying it to associated asset support would be a better fit for the crate, I can rework the feature split in that direction.