Support flags=re.UNICODE about sre_yield HOT 1 OPEN

It is worth stepping back and trying to establish what the user wants with Unicode support in the context of expanding a regex.

Even something fairly constrained like \w{3} in Unicode mode becomes a large sequence, putting pressure on memory if the developer isnt careful. I suspect the use cases for that are quite limited, and the developer is likely going to need to aggressively thin out the results. They would rather declarative have the results pre-thinned, so IMO usable Unicode support is highly dependent on #2. Technically supporting Unicode without good thinning mechanisms seems like a self-knockout given that Unicode support is likely to hurt CI build times significantly, and development time, and possibly even cause headaches in future enhancements. All those negatives are worth the pain if the users have a usable feature.

Likewise \d will often want to be expanded to only one numeral system.

In pywikibot there is quite a lot of code and use-cases to switch languages and switch numeral systems, especially to work in different calendar systems, and needing to mix natural and numerical strings, such as building generators of all century names (e.g. "3rd century BCE") and do that for each locale of Wikipedia, and build algorithms on top which work for any subdomain of Wikipedia. Those generators could easily be built using sre_yield, and I recall we had a few hacky attempts at similar approaches in the codebase. The need to mix numbers and natural language lends itself to having mappings of expandable regexes with keys for language codes.
No doubt I am forgetting some use case for mixing almost random parts of Unicode in the one algorithm, but all the ones which come to mind are like that -- they are generic algorithms that sit on swappable pre-defined segments of Unicode.

from sre_yield.