Fix rich-text bold/italic/underline parsing per ECMA-376

[dev-aliawan]

Summary

SharedString.textSpan in lib/src/sharedStrings/shared_strings.dart misparses three explicit-off OOXML boolean markers in rich-text runs:

• <b val="0"/> imported as bold=true
• <i val="0"/> imported as italic=true
• <u val="none"/> imported as Underline.Single

Root cause

The getBool helper used inside textSpan:

bool getBool(XmlElement element) {
  return bool.tryParse(element.getAttribute('val') ?? '') ?? true;
}

Per the Dart SDK, bool.tryParse only accepts the literal strings "true" / "false" (https://api.dart.dev/dart-core/bool/tryParse.html). Excel writes <b val="0"/> to mean explicitly-off — XSD boolean's lexical space allows "1" and "0" in addition to "true"/"false" — so bool.tryParse("0") returns null, the ?? true default fires, and the run is misread as bold on.

The underline switch-case has a sibling bug: any non-"double" value is mapped to Underline.Single, which forces explicit <u val="none"/> runs to import underlined.

Spec reference

• ECMA-376 §18.8.2 b (Bold) — val is W3C XSD boolean, default true when omitted. See Microsoft Learn's ISO/IEC 29500-1 excerpt.
• ECMA-376 §18.4.13 u (Underline) — ST_UnderlineValues includes none as an explicit off state.
• W3C XSD Datatypes §3.2.2.1 — boolean lexical space is {true, false, 1, 0}.

Reference implementation

openpyxl handles this correctly in descriptors/base.py:

class Bool(Convertible):
    def __set__(self, instance, value):
        if isinstance(value, str):
            if value in ('false', 'f', '0'):
                value = False
        super().__set__(instance, value)

This PR mirrors that behavior.

Impact

Downstream users importing xlsx files authored with Excel's "bold default + un-bold specific runs" pattern currently see every un-bolded run rendered as bold. Verified against a real 23-question content file (50+ <b val="0"/> runs) — flags now match openpyxl ground truth exactly.

Testing

Fix was verified end-to-end against real content. Happy to add unit tests matching the project's preferred style if you'd like — I didn't see existing coverage for the rich-text parsing path.