Incorrect Font Fallback Behavior (we fall back to Segoe UI sometimes!)

notes from @DHowett - we're also falling back to Segoe UI Symbol when box-drawing glyphs don't exist. We should have a smart internal font fallback table that we consult even when we allow customization in #2664.

Environment

Microsoft Windows [Version 10.0.18362.535]
Windows Terminal version (if applicable): 0.7.3451.0

Steps to reproduce

Print anything in Hebrew when using a font without Hebrew glyphs (e.g. Cascadia Code or Consolas).

Expected behavior

So, leaving aside RTL being tough, there's a very specific error here. Namely, font fallback in the code seems to be:
Consolas --> Lucida Console --> Courier New.
This should fail the first two, but the Hebrew charset is covered in Courier New, so that should be the font used here. If you set the font to Courier New, you can see that the font rendering itself is not messed up. Still RTL is tough, but -- the ransom note aspect of it is gone.

Actual behavior

With the benefit of super zooming in, it seems to me that the font being used for Hebrew is Segoe UI. I assume that it's some sort of system default, MSFT and whatnot, but that's really not good. Courier New may be jarring, as you'd expect from fallback, but given that it's at least monospaced I assume that the ransom note aspect of the text rendering here wouldn't happen. Segoe UI is not monospaced, and I think that's why you get the ransom note like variation in text sizes.

An important clarification / note: this is NOT a regression. This is not a new bug, it's been around forever. The only new thing is that I read the source code yesterday and realized that it wasn't supposed to happen.

Reproduce the issue by printing Hebrew in Windows Terminal with Cascadia Code or Consolas, then inspect the font-fallback implementation and its handling of missing glyphs. Confirm the fallback sequence and verify that Hebrew uses an appropriate monospaced fallback instead of Segoe UI; also check the existing box-drawing fallback behavior.