bug#62677: Merge flyspell-mode with flyspell-prog-mode

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 24 Sep 2023 07:08:56 -0700
> Cc: michael_heerdegen@web.de, jporterbugs@gmail.com, 62677@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Wed, 6 Sep 2023 11:51:14 -0700
> >> Cc: jporterbugs@gmail.com, michael_heerdegen@web.de, 62677@debbugs.gnu.org
> >>
> >> Here's the plan I'd propose: Add a new defvar-local
> >> `flyspell-use-prog-mode' or somesuch that major modes can set.  Now,
> >> when a user enables `flymake-mode' in a buffer where that variable is
> >> non-nil, the extra stuff done in `flyspell-prog-mode' gets done too.
> >> Then decide which built-in major modes that would benefit, and set that
> >> variable in them.
> >
> > SGTM.
> >
> >> Would `prog-mode' be a candidate though, or do we expect any modes
> >> inheriting from it to want the regular `flyspell-mode'?
> >
> > The former, I guess?
> 
> Thanks.  How does the attached patch look?

Looks good in general, but why deprecate and de-document
flyspell-prog-mode?  I can easily envision a major mode that doesn't
inherit from prog-mode, but still has defined syntax for comments and
strings: why not let users invoke flyspell-prog-mode in those cases?
Moreover, users might have customizations that reference
flyspell-prog-mode, and I see no reason to annoy them with obsoletion
warnings.

IOW, we just made the users' lives easier by automatically activating
flyspell-prog-mode when we know it's appropriate, we are not saying
that what flyspell-prog-mode does is incorrect or suboptimal.