WIP: Expose current TextAttributes from the underlying console API.

[jazzdelightsme]

Summary of the Pull Request

This is not a polished PR that is ready to merge; it demonstrates a
direction for which I need to get buy-off from the team before pursuing
further.

I'm currently working on implementing the XTPUSHSGR/XTPOPSGR control
sequences (WIP PR here, which requires saving a [stack of] text
attributes, and not just the legacy attributes, but full RGB colors,
etc.

My first instinct was to implement the "business logic" (the stack) in
the AdaptDispatch layer, but that will require getting the [full] text
attributes from the underlying console API. This is not a terribly
"invasive" change, but it is exposing new stuff at a layer boundary.

Put another way, this means pound-including the
"../buffer/out/TextAttribute.hpp" header in a few places outside of
"buffer/out", and is that okay, or does that header need to be kept
private and isolated?

So there are a few ways this could go:

1. You folks might say "ugh, no!", and:
   1. I could push (haha) the business logic of pushing and popping text
      attributes down another layer (so AdaptDispatch just forwards on
      the PushGraphicsRendition call to the lower layer, OR
   2. You suggest a different, cleaner way of exposing the text
      attributes.

OR

2. Maybe you think this general direction is fine, but maybe you have
   some particular requests that I do certain things differently (I
   totally understand being picky about stuff that cuts across API
   layers).

What do you think?

References

Related: PR #1978
Related: Issue #1796

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

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

none

[zadjii-msft]

Largely, this is exactly what I would have done. I am worried though that the implementation as it is leaves the opportunity for a caller to accidentally modify the buffer's state.

[jazzdelightsme]

This has been fleshed out and incorporated as part of my main PR (#1978).