Smithy Model Gen Part 2

[sbaluja]

Issue #, if available:

Description of changes:

• Transformation Pipeline and interface
• ShapeRenderer interface
• Proper decoupling of renderer types (Request, Result)
• Event stream operation generation
• Correctness fixes

Check all that applies:

• Did a review by yourself.
• Added proper tests to cover this PR. (If tests are not applicable, explain.)
• Checked if this PR is a breaking (APIs have been changed) change.
• Checked if this PR will not introduce cross-platform inconsistent behavior.
• Checked if this PR would require a ReadMe/Wiki update.

Check which platforms you have built SDK on to verify the correctness of this PR.

• Linux
• Windows
• Android
• MacOS
• IOS
• Other Platforms

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sbiscigl]

in multiple places in the code we have classes that are more or less

publc class FileGenerator {
  public void function() {
     if(protocol.isJsonLike()) {
        ... do json thing
     } else {
       ... do xml thing
     }
  }
}

theres a couple of issues i see with that, logic for protocols is scattered between classes, and that xml is used at a fallback. protocol should be selected once in the generator then injected into generator classes, where they dont need to remember protocol specific logic. i.e.

public interface ProtocolSpecificCommands {
  void WriteSerializerHeaders();
  // whatever others functions
}

public class JsonCommands implements ProtocolSpecificCommands {
  @override
  void WriteSerializerHeaders() { .. do json stuff}
}

public class Generator {
  private final ProtocolSpecificCommands commands;
  public void run() {
    commands.WriteSerializerHeaders(... pass in scope)
  }
}

public class Plugin {
  ProtocolSpecificCommands commands = new JsonCommands();
  Generator generator = new Generator(commands)
}

that way its easier to add more protocols, you dont need to add another branch statment, and you can handle the "no such protocol, throw exception" once instead of in multiple places.