Re-export of client SDK type definitions

[dmeehan1968]

The services that @effect-aws create don't expose the SDK client type definitions. Depending on the client, these can be useful for specifying aspects of the client command input. Whilst its possible to specify literals, this can make the code less maintainable overall.

For example, in the Timestream client, the following types are useful when building the writeRecords input:

import { _Record, MeasureValue, MeasureValueType, TimeUnit, Dimension } from "@aws-sdk/client-timestream-write"

At present, because @effect-aws doesn't re-export these values, its necessary to install the aws-sdk client in order to be able to access them in the application code. That can also then raise issues with mismatched client versions which might lead to discrepancies/conflicts (not necessarily in the types, but I've seen instances of the @smithy dependencies conflicting when there are mixed SDK client versions.

I don't know if its possible to identify what these types might be via the codegen.

[floydspace]

currently @effect-aws clients require installing @AWS-SDK dependencies as direct peer dependency. anyway you have to install them... (pnpm just installs peers it for you, but npm will complain)
but I agree better if @effect-aws client would be the only dependency to install, and indeed in this case we will have to reexport many things from @AWS-SDK (or make them effectful too). I will think about this, maybe will discuss with some peers on the effect days conf..

[kiliancs]

I am interested in where this landed. The need of @aws-sdk as a peer dependency prevents full separation of interface vs implementation, e.g. if you want a consuming package to only work with the service. A re-export would still allow me to disallow import of non-explicit dependencies via eslint.