[sbiscigl]

Issue #, if available:

Description of changes:

When an output member's getter would have the same name as the result class, the model generator adds another Get, but the waiter generator didn't. For an operation GetFoo with an output member fooResult:

class GetFooResult {
  inline const FooResult& GetGetFooResult() const { return m_fooResult; }
};

// waiter before, doesn't compile
result.GetFooResult().GetStatus()

// waiter after
result.GetGetFooResult().GetStatus()

Regenerating all clients produces no changes.

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.

[wty-Bryant]

wonder if this null reset for resultClassName is really needed since the TopLevelVisitor creates a new emitter for every result access

[sbiscigl]

got rid of it, the right side of a subexpression gets its own emitter now so only the first field can get renamed