Add ResizeImage.policy

[tvolkert]

This adds a new ResizeImage.policy property that controls how ResizeImage will interpret its width and height properties. The existing behavior is preserved via ResizeImagePolicy.exact (default), but there is now the option to use ResizeImagePolicy.fit, which satisfies the use case outlined in #118543.

The API doc assets were added in flutter/assets-for-api-docs#209

Fixes #118543

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
• I signed the [CLA].
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is [test-exempt].
• All existing and new tests are passing.

[dnfield]

LGTM with some doc nits

[dnfield]

It'd be nice to be more specific about how the new aspect ratio is applied.

Maybe

output image will have the spedified width and height, with the aspect ratio of the new width and height regardless of whether it matches the intrinsic aspect ratio of the image's width and height.

[dnfield]

nit:

This may result in a different aspect ratio than the aspect ratio specified by the target width and height, if for example the height gets clamped downwards but the width does not.

[dnfield]

Also, consider mentioning that this is similar to [BoxFit.fill] with consideration for null values on width and height, so setting one of those to null would end up corresponding to [BoxFit.fitWidth] or [BoxFit.fitHeight].

Consider mentioning that the fit member is similar to [BoxFit.contain].

I'm not sure if that would confuse more people or just lead to asking why we don't use BoxFit here, but to me having that linkage helps.