Use NCURSES_EXT_COLORS and NCURSES_EXT_FUNCS to check extended color support

[shugo]

No description provided.

[Copilot]

Pull request overview

Updates the curses extension’s compile-time detection of ncurses “extended color” support to use ncurses header feature macros instead of extconf-generated HAVE_* checks, and applies that flag across the extended color call sites.

Changes:

• Add SUPPORT_EXTENDED_COLORS derived from NCURSES_EXT_COLORS and NCURSES_EXT_FUNCS.
• Use SUPPORT_EXTENDED_COLORS to select between init_extended_*/extended_*_content and the classic APIs.
• Simplify the Curses.support_extended_colors? documentation and implementation to rely on SUPPORT_EXTENDED_COLORS.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

SUPPORT_EXTENDED_COLORS is derived only from NCURSES_EXT_COLORS/NCURSES_EXT_FUNCS (header-level macros) and no longer incorporates the extconf feature probes (HAVE_INIT_EXTENDED_PAIR, HAVE_INIT_EXTENDED_COLOR, etc.). That can make builds less robust in header/library mismatch scenarios (e.g., headers advertise extended support but the linked curses library lacks one of the extended_* symbols), leading to compile/link failures. Consider defining SUPPORT_EXTENDED_COLORS to also require the relevant HAVE_* macros (or keeping the per-call #ifdef HAVE_... guards) so we only call extended APIs when extconf verified they exist in the linked library.