Alias type name hides interface type name in generated input/output types

[DanielBauman88]

Alias type name hides interface function name.

This led me down an interesting exploration of go and how a field can hide a function given by an anonymous struct field.

It makes the code confusing to someone reading it. What is the benefit of naming these the same thing? If there's no practical benefit - why not have the interface method and the type alias have different names? The method isn't exported anyway and won't clutter the autocomplete of customers.

[skmcgrail]

This concept was introduced when we added support for Smithy document shapes in the code generator. The background for this decision was we wanted to forgo making a one-way door decision on whether the auto-generated types within a service's client package should be usable as values for a document shape member. If we were to allow these shapes then we would have to make a standardized decision on the serialization behavior, and ensure that is consistent with other SDK implementations. We may lift this in the future, but for the moment this sentinel value allows us to detect if such an auto-generated type is being used as a document value, and return an appropriate error in those instances.

The downside to this is that it does require users to specify the field names when using structure initialization.