Test entry points, call all Python apps with --help

[plimkilde]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Closes #834

Now that GDAL 3.9 has landed, we can test the proper entry points (Python apps, called without the .py extension). Also incorporated are changes (as a result of upstream GDAL fixes) so that all of these apps are now tested with --help, see OSGeo/gdal#8717.

There has been a bit of churn on GDAL upstream regarding these entry points, see:

• Python bindings: define entry_points.console_scripts OSGeo/gdal#8718
• [Backport release/3.8] Python bindings: define entry_points.console_scripts OSGeo/gdal#8774
• Python utilities: provide launcher scripts OSGeo/gdal#8811
• Python scripts: define entry_points.console_scripts to have launcher shell/exe scripts OSGeo/gdal#8815
• swig/python/setup.py.in: workaround easy_install behavior on Windows to keep .py scripts (fixes #8811) OSGeo/gdal#8824

The commands including .py are still the ones shown in GDAL docs, so for now I test both e.g. gdal_calc.py and gdal_calc.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[gillins]

Thanks @plimkilde @rouault this is a huge step forward and will definitely make life much easier!

[plimkilde]

Rebased to fix build number conflict