Add presignable trait to Smithy

[kggilmer]

Issue #, if available: N/A

Description of changes:

• Adds an annotation trait that provides context about which specific service operations may have client-side presigners. This state is currently modeled in customizations in various SDKs. Some samples: Java v2 (in code, eg S3), Go v2, and Kotlin SDKs.

NOTE: this trait only models a specific use case for presigners: generators. It does not model "presign url autofill parameters" of some services due to current migration away from this to other approaches.

NOTE: This PR was initially created here, but moved to personal fork as repo rights were removed during PR work.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[mullermp]

I like the idea of code generated presigners. It provides a good customer experience similar to waiters, paginators, resource models, etc. I do think however that presigning is a function of Sigv4/a and the signer, not generic service modeling. I think if there was a presignable trait, it certainly needs to only apply to sigv4 services or possibly a property baked into sigv4/sigv4a traits. Since pre-signed urls work for any sigv4 operation in theory, I would prefer to see SDKs have a "presigned_url: true" option passed to operation methods as options, like create_bucket(bucket: 'foo', presigned_url: true), that generated a pre-signed url (as opposed to sending the request) for any sigv4 operation for any service.

[kstich]

We haven't validated that an operation-level trait is the correct path forward for modeling if an operation can have a presigned url generated or how this would need to interact with other traits, like sigv4. Given this and that this PR is now significantly out of date, I'm closing it. We can reopen this PR if it's the basis for the future design