gh-150474: Fix RFC 2231 charset handling in the email header parser

[lpyu001]

While writing test cases, I found that the for loop here iterates over a Value token list whose only child is the Attribute (or QuotedString) containing the terminal, for example:

token = Value([
    Attribute([
        ValueTerminal("us-ascii", "extended-attrtext"),
        CFWSList([...]),
    ])
])

As a result, the loop never reaches the extended-attrtext terminal, so the break condition is never satisfied. Parameter.charset is therefore taken from the enclosing token and includes any CFWS following the charset. It also means that the loop's intended purpose—retyping the extended-attrtext terminal as attrtext—cannot take effect.

I decided to fix this by first descending into the child token that contains the charset, then retyping the actual extended-attrtext terminal as attrtext. The charset value is taken from the child token's stripped_value, so any surrounding CFWS is preserved in the parse tree but excluded from Parameter.charset.

• Issue: Email Header Parser issue t.token_type == 'attrtext' #150474