Simplify documentation related to Windows builds

Hi all,

As promised around thread [1] that has moved the docs related to
Windows into a new sub-section for Visual, here is a follow-up to
improve portions of its documentation, for discussion in the next CF.

Some of my notes:
- How much does command line editing work on Windows? When it came to
VS, I always got the impression that this never worked. Andres in [2]
mentioned otherwise because meson makes that easier?
- ActiveState perl should not be recommended IMO, as being able to use
a perl binary requires one to *register* into their service for tokens
that can be used to kick perl sessions, last time I checked. Two
alternatives:
-- MinGW perl binary.
-- strawberry perl (?) and Chocolatey.
-- MSYS
- http://www.mingw.org/ is a dead end. This could be replaced by
links to https://www.mingw-w64.org/ instead?

At the end, the main issue that I have with this part of the
documentation is the lack of consistency leading to a confusing user
experience in the builds of Windows. My recent impressions were that
Andrew has picked up Chocolatey in some (all?) of his buildfarm
animals with Strawberry Perl. I've had a good experience with it,
FWIW, but Andres has also mentioned me a couple of weeks ago while in
Prague that Strawberry could lead to unpredictible results (sorry I
don't remember all the exact details).

Between MSYS2, mingw-w64 and Chocolatey, there are a lot of options
available to users. So shouldn't we try to recommend only of them,
then align the buildfarm and the CI to use one of them? Supporting
more than one, at most two, would be OK for me, my end goal would be
to get rid entirely of the list of build dependencies in this "Visual"
section, because that's just a duplicate of what meson lists, except
that meson should do a better job at detecting dependencies than what
the now-dead MSVC scripts did. If we support two, the CI and the
buildfarm should run them.

I am attaching a patch that's an embryon of work (little time for
hacking as of life these days, still I wanted to get the discussion
started), but let's discuss which direction we should take moving
forward for 17~.

Thanks,

[1]: https://www.postgresql.org/message-id/ZQzp_VMJcerM1Cs_@paquier.xyz
[2]: https://www.postgresql.org/message-id/20231116010703.gtjyepw7jsvyg6qr@awork3.anarazel.de
--
Michael