[ECR] [Lifecycle Policy on Signed images]: Support expiring unsigned images

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
What do you want us to build?
A lifecycle policy that expires and cleans up unsigned images. In particular, images without a prod signature.

**Which service(s) is this request for?**
ECR

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
Your container registry storage consumption is growing exponentially. You worry about wasting storage, and the cost. You recall that historically, [Dockerhub had 10PB of images that had not been pulled in the last 6 months](https://www.docker.com/blog/scaling-dockers-business-to-serve-millions-more-developers-storage/). Is it safe to delete them? All of them?
You also worry about deleting legacy images that may or may not be still running on static docker servers. You might keep only the last 10 image versions. But which of those last 10 were deployed to production? For some teams, 2 of their last 10 were deployed to production. For others, not one of their last 100 image versions were deployed to production.

**Are you currently working around this issue?**
Not currently using lifecycle policies. ECR is growing...

**Additional context**
Its a thought experiment. What alternatives are there to `sinceImagePushed` and `imageCountMoreThan` that can identify safe-for-deletion images across a range of team maturities?

Imagine there's a production runtime policy that requires all images to be signed with a prod signature. If we can identify images that were deployed to prod by their verifiable prod signature, is it safe to clean up the rest? Can the same lifecycle policy logic be extended for other signature e.g. dev signed, UAT signed, vulnerability scan signed ?

**Attachments**
N/A

No repository files, tests, or implementation entry points are identified. Start by examining ECR lifecycle policies and the existing sinceImagePushed and imageCountMoreThan criteria; done would require a defined way to identify unsigned or non-production-signed images for cleanup, including the behavior for other signature types.

Written by the indexing model from the issue text.