Fix error when a PrimaryHDU has a "GROUPS = 1" keyword

[saimn]

GROUPS = 1 was interpreted as GROUPS = T which is wrong.
This occurs on some Euclid commissioning file so I would like to make a bugfix release soon (with also the nddata fix).

In [1]: %astropy
Numpy 1.25.0
Astropy 6.0.dev302+g6fd7ebdfc

In [2]: hdu = fits.PrimaryHDU()

In [3]: hdu.header["GROUPS"] = (1, "not a groups HDU")

In [4]: hdu.header
Out[4]: 
SIMPLE  =                    T / conforms to FITS standard                      
BITPIX  =                    8 / array data type                                
NAXIS   =                    0 / number of array dimensions                     
EXTEND  =                    T                                                  
GROUPS  =                    1 / not a groups HDU                               

In [5]: hdu.writeto("test.fits")

In [6]: fits.open("test.fits")
WARNING: An exception occurred matching an HDU header to the appropriate HDU type:  [astropy.io.fits.hdu.base]
WARNING: The HDU will be treated as corrupted. [astropy.io.fits.hdu.base]
Out[6]: [<astropy.io.fits.hdu.base._CorruptedHDU object at 0x7f5640149f10>]

[github-actions]

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

[saimn]

This change is not strictly needed since _NonstandardHDU comes after the other main extensions when finding the correct HDU class, but as the comment says this check is useless.

[astrofrog]

Checked the standard and this looks right, thanks!