Rollback and Prune previous versions

### Describe the feature

This may be more a pertinent to using SAM template's `AutoPublishAlias` or `SemanticVersion` rather than dotnet CLI, but deployment creates several artifacts in the S3 deployment bucket and never removes them. It's not clear how to get back to a previous version (either via CLI or in Console, as no changeset history is listed?), and I've only seen suggestions for manually cleaning up old stuff or [awkward lifecycle policies](https://github.com/aws/aws-sam-cli/issues/2980) or installing random [1stparty](https://aws.amazon.com/blogs/containers/enable-continuous-deployment-based-on-semantic-versioning-using-aws-app-runner/) or [3rdparty](https://stackoverflow.com/questions/66677614/what-is-the-best-approach-to-clean-up-old-lambda-versions) plugins to do it for you.

The [Serverless Framework's prune plugin](https://www.serverless.com/plugins/serverless-prune-plugin) handles this for the Lambda versioning, and I think it already cleans up old deployment artifacts?

### Use Case

* Clearing old micro-version/minor changes from test attempts
* Reverting deployment with breaking change

### Proposed Solution

Specifying a major/minor version number in template and remembering to update it when you want an explicit version, or deploying with an `--autoversion` flag; either should save separate changesets (is that how you're supposed to do it with Cloudformation Stacks?). Then:

> dotnet lambda rollback-stack --v

or

> dotnet lambda rollback-stack --v "- dotnet lambda rollback-stack # just to previous version

To get back to the indicated version.

Also, specifying something like `--retainVersions 5` to keep the last 5 deployments for rollback.

### Other Information

_No response_

### Acknowledgements

- [ ] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### Targeted .NET platform

Any

### CLI extension version

Package Id Version Commands
------------------------------------------------------------------------
amazon.lambda.testtool-3.1 0.10.0 dotnet-lambda-test-tool-3.1
amazon.lambda.tools 5.10.4 dotnet-lambda
dotnet-xscgen 2.0.662 xscgen

### Environment details (OS name and version, etc.)

Windows

Start by reviewing the existing dotnet-lambda deployment commands and the AutoPublishAlias and SemanticVersion behavior mentioned in the issue. Compare how CloudFormation stack history, Lambda versions, and S3 deployment artifacts are handled today. Done would require an agreed design and implementation for version rollback plus retention or pruning of older deployments.

Written by the indexing model from the issue text.