Per language stylistic set idea.

So... a problem I noticed while browsing through the issues is token compatibility. I had that issue myself with <- in C++ which I mentioned in #1422. The solution rn for it is stylistic sets. Which work. Especially for text editors that give you per language font options. But I feel like that will become unwieldy the more ligatures get added and the more possible conflicts it could cause the number of stylistic sets to spiral out of control.

So I propose instead of having stylistic sets to enable or disable X ligature instead have each stylistic set enable and disable tokens on a per language basis (with descriptive names). Considering most languages have a strict set of tokens this seems to be a great way to avoid conflicts and false positives.

For example, have a stylistic set named "C++" (or "SS_C++") that disables all ligatures that aren't used in C++ (including <-). #1365 mentioned squashing ?. doesn't make sense in Rust so the Stylistic Set named "Rust" (or "SS_Rust") will not have a ligature for ?.. The stylistic set for Haskell will enable what's now called "ss09". All of these will also disable all other ligatures that don't correspond to operators in that language. Just in case.

This also leaves the question of "what should the default be". I think the default as it currently is is fine. So people get a good enough compatibility without fiddling and only enable a Stylistic Set if it becomes a problem for them.

Of course I am aware this is quite a task. And I wish I knew enough about font design to make a fork of Fira that implements that feature because I am sure that will require a rethinking of the entire font. And there might be font or language design considerations that would make this impractical. For all I know you already thought of that idea ages ago. But I still wanted to give my 2 cents.

No files, tests, or entry points are identified in the issue. Start by evaluating the proposed per-language stylistic-set design against the existing ligature and token-compatibility behavior; the work is done when feasibility, scope, and a concrete implementation path are established.