Support versioned S3 artifacts for lambda package-ci code uploads

Allowing the use of versioned S3 buckets for code artifacts could greatly simplify management of old versions & deduplication of new versions.

## Describe the Feature
When you repackage the same code artifact, it could be uploaded as a new version of the same S3 object

### Is your Feature Request related to a problem?
Managing version history across many thousand timestamped items is much more complex than using a single versioned S3 object.

## Proposed Solution
* If versioning is enabled for the target bucket, don't add a timestamp to the target location in `UploadToS3Async`: https://github.com/aws/aws-extensions-for-dotnet-cli/blob/d32048587fcbac721e183dcb260d3f6868cabfc6/src/Amazon.Common.DotNetCli.Tools/Utilities.cs#L556
* Don't add a timestamp to the generated zip file name here: https://github.com/aws/aws-extensions-for-dotnet-cli/blob/6b3c0eaf04bb62995ca1c5dd71b0db7e564e8b74/src/Amazon.Lambda.Tools/TemplateProcessor/TemplateProcessorManager.cs#L260

## Additional Context
We currently have many thousand objects in our S3 buckets from our CI system. Managing versioned artifacts is a lot simpler, particularly where ETags are able to be file hashes. Making these changes may also make it a lot simpler to only upload changed artifacts, per #83

---

This is a :rocket: Feature Request

Start with UploadToS3Async in src/Amazon.Common.DotNetCli.Tools/Utilities.cs and the zip naming logic in src/Amazon.Lambda.Tools/TemplateProcessor/TemplateProcessorManager.cs. Review how versioned target buckets should affect both locations, then verify that repeated packaging uses the requested S3 object behavior without timestamps.

Written by the indexing model from the issue text.