Improve TSF color filtering logic (re: QQPinyin) (#19117)

If an IME provider sets both `crText` and `crBk` we should respect this,
but the previous logic would incorrectly assert for `crLine !=
TF_CT_NONE`.

## Validation Steps Performed
❌ I'm not aware which TSF even sets these colors in a
way that's compatible with us in the first place...

(cherry picked from commit f2b30b4)
Service-Card-Id: PVTI_lADOAF3p4s4AmhmQzgck4T8
Service-Version: 1.22

Author: lhecker

src/tsf/Implementation.cpp

@@ -719,17 +719,12 @@ TextAttribute Implementation::_textAttributeFromAtom(TfGuidAtom atom) const
     // the others is likely not properly tested anyway, so we reject those cases.
     // After all, what behavior do we expect, if the IME sends e.g. foreground=blue,
     // without knowing whether our terminal theme already uses a blue background?
-    if (da.crText.type == da.crBk.type && da.crText.type == da.crLine.type)
+    if (da.crText.type != TF_CT_NONE && da.crText.type == da.crBk.type)
     {
-        if (da.crText.type != TF_CT_NONE)
-        {
-            attr.SetForeground(_colorFromDisplayAttribute(da.crText));
-        }
-        if (da.crBk.type != TF_CT_NONE)
-        {
-            attr.SetBackground(_colorFromDisplayAttribute(da.crBk));
-        }
-        if (da.crLine.type != TF_CT_NONE)
+        attr.SetForeground(_colorFromDisplayAttribute(da.crText));
+        attr.SetBackground(_colorFromDisplayAttribute(da.crBk));
+        // I'm not sure what the best way to handle this is.
+        if (da.crText.type == da.crLine.type)
         {
             attr.SetUnderlineColor(_colorFromDisplayAttribute(da.crLine));
         }