Migrate to Smithy's DirectedCodegen pattern

[jdisanti]

Smithy now provides a DirectedCodegen interface that essentially replaces the need to write a CodegenVisitor, and standardizes the patterns that the newer Smithy code generators have established.

I spent some time investigating what it would take to refactor our code generator to use the DirectedCodegen approach, and discovered this list of smaller refactors we can do that will make the transition a lot easier:

• Use NodeMapper.deserialize to parse -RustSettings instead of manual parsing:

S deserialized = new NodeMapper().deserialize(settingsNode, settingsType);

This method of parsing is required to use DirectedCodegen since the CodegenDirector does the parsing.

• Replace OperationNormalizer with ModelTransformer.createDedicatedInputAndOutput
• Refactor existing codegen to write its file entries into a Smithy FileManifest
• Eliminate direct use of RustSymbolProvider; only the SymbolProvider interface may be used in codegen

Additionally, we would need to break the Client/Server inheritance model for the RustSettings and CodegenContext classes since the types for these need to be known at compile time. The best way to do this would probably be to keep them, but they go into their respective client/server modules, and then have a ClientDirectedCodegen and a ServerDirectedCodegen. Essentially, the server codegen would need to become its own Smithy plugin, and the shared code between client and server would need to go into a core module.

Once all of these refactors are done, it looks like it should be possible to migrate, but it will still be a considerable amount of work.

[jdisanti]

Replacing the OperationNormalizer is blocked on smithy-lang/smithy#1373