Fixed DirectX RTL text issue where it'd be over other text / offscreen

[schorrm]

This is a partial fix of #538 . This does not change the Console RTL behavior, it does however fix an issue in the rendering. Basically, DirectX expects the origin to be on the right if it is going to draw RTL text. This PR is a simple fix for that. Rather than draw with the left point and then move the origin rightwards, we check if it's RTL, if so, we move the origin rightwards immediately, and then draw. LTR rendering is unchanged.
This doesn't fix underlying questions of RTL handling in the console. It's just a render bugfix. However, this render bugfix should still be a big help and solve the low-hanging issues.

PR Checklist

• Closes #xxx
• CLA signed. If not, go over here and sign the CLA
• Tests added/passed
• Requires documentation to be updated
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Validation Steps Performed

Behavior was tested. No changes were made to underlying console.
Three sample cases:

1. RTL text input
   Before:
   
   After:
   
2. Hebrew Output
   Before (the Hebrew text is all being drawn to the left of the screen, hence the phantom text):
   
   After:
   
3. Mixed Output
   So, this is where this is partial. Due to inherent stuff with RTL behavior, it doesn't look perfect. But the rendering itself is no longer at fault.
   Before:
   
   After:
   

[schorrm]

Just a note: the boxes in the prompt aren't a problem, they're just because Courier New doesn't support powerline.

[zadjii-msft]

Honestly, this fix seems reasonable to me, with the caveat that RTL definitely still won't work right just better. We'll need a comprehensive design on the right way to handle RTL in the future, but this seems to me like it'll make cating RTL files work in the meantime.

[schorrm]

Pretty much, it'll make basic input / output with RTL in general work tolerably. It's not just cating files, any RTL input or text runs into this problem big-time. This isn't just for cat.
More generally, yes, this isn't the grand unified solution to RTL directionality. But the bugfix is valuable nonetheless. It takes Windows Terminal RTL support from useless to tolerable, and that's not nothing.
And I would find it hard to imagine a long-term implementation that won't take into account the central thing that this code does: account for the fact that DWrite takes the right x-point for the writing call of an RTL sequence, not the left one.

[miniksa]

Pretty much, it'll make basic input / output with RTL in general work tolerably. It's not just cating files, any RTL input or text runs into this problem big-time. This isn't just for cat.
More generally, yes, this isn't the grand unified solution to RTL directionality. But the bugfix is valuable nonetheless. It takes Windows Terminal RTL support from useless to tolerable, and that's not nothing.
And I would find it hard to imagine a long-term implementation that won't take into account the central thing that this code does: account for the fact that DWrite takes the right x-point for the writing call of an RTL sequence, not the left one.

Yeah, this is righteous for that reason. Let's get it cleaned up and merged!

[miniksa]

Excellent, thank you. Just get the code formatter check happy and I think this is good to go.

[schorrm]

Format check is now pleased, praised be the Clang-Format VStudio add-on.

[DHowett-MSFT]

This is straightforward! Thanks for working on it.

[ghost]

🎉Windows Terminal Preview v0.3.2142.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download

[donno2048]

...
Behavior was tested. No changes were made to underlying console. Three sample cases:

1. RTL text input
   Before:
   
   After:
   
   ...

"ריץ טארנר הוא ממש אחלה גבר" 💀