Split `CodegenContext` and children (#1473)

This commit splits each of:

* `CodegenContext`,
* `RustSettings`; and
* `CodegenConfig`

into two variants: one for the `rust-codegen` client plugin and another
for the `rust-server-codegen` plugin.

(`CodegenConfig` is a property of `RustSettings`, which is a property of
`CodegenContext`; they constitute pervasive read-only global data that
gets passed around to the code generators).

This allows each plugin to evolve separately, defining different
settings and passing around a tailor-made code-generation context.

Client-specific generators should now use:

* `ClientCodegenContext`,
* `ClientRustSettings`; and
* `ClientCodegenConfig`.

Likewise, server-specific generators should now use:

* `ServerCodegenContext`,
* `ServerRustSettings`; and
* `ServerCodegenConfig`.

This is a more robust and maintainable approach than the current one,
where both generator types have to read possibly null values (because
they don't make sense for a client/server target), and plugins have to
populate settings that are not relevant for the crate they're
generating. For example, the server plugin has to populate and pass
around the settings `renameExceptions`, `includeFluentClient` and
`addMessageToErrors` even though it never uses them and don't make sense
for it.

As of writing these client and server specific classes are very similar,
but in the future they will evolve in separate ways (for example, #1342
will add symbol providers for constrained shapes that only make sense in
a server code-generation context).

Common properties have not been duplicated however. Instead, utilizing
inheritance, code-generation context that is common to _all_ plugins can
be placed in:

* `CoreCodegenContext`,
* `CoreRustSettings`; and
* `CoreCodegenConfig`.

This way, generators that are shared by both client and server can take
in `CoreCodegenContext`. If they need to tweak the code they generate in
small and self-contained places, they can utilize the `CodegenTarget`
flag-like enum to disambiguate, like they have always been doing.

Note this change also makes `RustDecorator`s be targeted for clients or
servers, by making them generic over the code-generation context. When
loading the decorators from the classpath and combining them into one in
the executed smithy-rs plugin, all of them need to either target clients
or target servers. This makes sense: after all, all of the decorators
that conform the AWS Rust SDK are client-specific.

Closes #828.