fix(css_parser): fix is at unicode range check

[suxin2017]

Summary

fix unicode_range check #3743

Test Plan

add snapshot test

[codspeed-hq]

CodSpeed Performance Report

Merging #3745 will not alter performance

_{Comparing suxin2017:fix-3743 (068b798) with main (7bcda36)}

Summary

✅ 99 untouched benchmarks

[Conaclos]

Dummy question: does not this reveal an issue in our lexer? If I understand correctly our lexer can output three different token sequences that are all Unicode range: id(u) token(+), id(u) number(_) and id(u) dimension(_). Should we output a dedicated token UnicodeRange?

Note: this can be left for a future PR.

[suxin2017]

Upon observing the lexer code, I found that the corresponding T![U+] as start, CSS_UNICODE_RANGE_WILDCARD_LITERAL CSS_UNICODE_CODEPOINT_LITERAL represents a numeric value, but we need to pass a Context to get the corresponding Token.I don't see an example of using context in other is_at methods， I'm not sure it's right to just default to set Unicode_Range_Context

[Conaclos]

@togami2864 @denbezrukov any opinion?

[Conaclos]

@suxin2017

Thanks for the fix! I think we can merge the fix and decide later if we need to move some logics to the lexer.