[gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

[Greg Troxel]

1) README.md points to build hints (my fault if that's wrong..):

  https://gdal.org/development/building_from_source.html

but really there is crucial information (like that a C++ compiler is
required!) at

  https://gdal.org/development/dev_environment.html

which is misplaced, because people are who merely intending to compile
gdal but not contribute to it, still need to know.  I almost didn't even
look at it before writing that it wasn't documented which C++ flavor is
needed, because it was obviously not about what I needed to know.

How do we want to fix this?

  move the prereqs into building_from_source (and probably flip that to
  before dev_environment)

  add a pointer in building_from_source that even for building as a
  user, see the prereqs listed in dev_environment

  something else?  (Overall I find the organizational intent hard to
  follow.  I would think "how to build from source" would be first, and
  then if people are getting help to set up an environment where they
  can run tests, make changes, etc. get into things that a user just
  building doesn't need to know.)

I lean to the first option as easy and good enough to address the
problem.

2) NEWS for 3.9 does not mention that there is now a requirement for a C++17
compiler.   I'm not complaining about the new language requirement,
given that 24 > 17 + enough, but that's a big deal, and it requires
packagers to code for that because not every compiler supports C++17.
gcc says

  https://gcc.gnu.org/projects/cxx-status.html#cxx17

you need gcc8.

It turned out that gdal 3.9 didn't build on NetBSD 9, and someone coded
the package for c++17 (which is easy).

Increased build requirements are a big enough deal that they belong up
front in NEWS.  If not in "in a nutshell", there should probably be a
"changes in requirements" section immediately after that.  (My view is
that building from source is the standard approach even if most don't,
and that because people use packaged binaries, packagers are a
particularly import audience, carrying the weight of all their users.
There are enough older/LTS things out there that one can't assume the
compiler supports newfangled stuff like c++17.  We can just about now
assume that c++11 support is present.)

3) The person also marked gdal for c17, but I can't find that in the
"dev_environment" page - it says c99.  It's also not in NEWS.  This may
be overzealous, and I'll ask.  Mentioning it because I'm already
writing.


Thanks,
Greg