Lifecycle policies for Lambda Resources

**Note**
> * Please vote on this issue by adding a 👍 reaction 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 providing additional feedback, please leave a comment

**Description**
We are exploring supporting lifecycle policies for versioned Lambda resources. With this feature, customers could delete multiple versions at once via a retention policy. We are exploring "max versions", "last invoked", and other qualifiers to automatically delete versions that do not match the policy when you create a new version or update a resource.

**Additional context**
1. What types of actions would you want to take, for example, label a function as deprecated, delete a layer version, block invokes, etc.?
2. What types of timestamp based rules would you write, for example, 1 year after function version create date do x.
3. Are there any other attributes you would want to reference in your policy?
4. Do you need to write policies to delete resources based on the status of other resources, for example, delete all function versions that reference outdated runtimes?
5. How would you want to handle dependencies for example, would you want to automatically delete function versions associated with a specific layer version?

これは、maximum-version、last-invoked、timestamp、status、および依存関係のルールを含む、バージョン管理された Lambda リソースのライフサイクルポリシーに関する探索的なリクエストです。ファイル、テスト、実装のエントリポイント、完了条件は特定されていません。現在、この issue は着手可能な変更を定義するのではなく、コミュニティからのフィードバックを求めています。

索引モデルが issue の本文から書いたものです。