Proposal: add lang:* labels for language-specific issues

[thejesh23]

A growing share of issues and PRs are scoped to a single language ecosystem — Ruby/Rails import resolution (#463), PHP call-graph (#367), Rust feedback (#413), C++ ignore patterns (#479), Wolfram support (#416), past Dart direction (#436),
and Python/TypeScript-specific bugs scattered through the tracker. Today the only labels are GitHub defaults (bug, enhancement, question, …), which means a contributor who only knows Ruby has no way to find the Ruby-shaped work, and a
maintainer triaging "all PHP issues" has to grep titles.

I think we're at the point where a lang:* label axis would pay for itself. Proposing a starter set covering languages we already parse or have open issues for:

• lang:python
• lang:typescript (covers JS/TS/Node)
• lang:rust
• lang:go
• lang:java (covers Kotlin)
• lang:cpp (covers C/C++)
• lang:csharp (covers .NET)
• lang:ruby
• lang:php
• lang:other — catch-all for Swift, Dart, Wolfram, Mathematica, etc. so the long tail still gets one tag without label sprawl

Rules of thumb so this doesn't drift:

1. A lang:* label means the bug, feature, or behavior is specific to that language's parser / import resolver / call graph. General improvements stay unlabeled.
2. Multi-language issues get multiple lang: labels (max 3) — beyond that it's a cross-cutting issue and shouldn't be language-tagged.
3. Promote lang:other → lang: once a language hits ~3 open issues, so the taxonomy stays grounded in actual demand instead of speculative coverage.

Open questions for the community:

• Should we collapse lang:typescript/lang:javascript or keep them split? (I'd collapse — the parser pipeline is shared.)
• Color convention — match GitHub's linguist colors per-language, or one shared color for the whole axis?
• Should lang: labels also apply to PRs, or issues only?