Fix #6319: [Win32] don't use clipping; draw whole screen every frame

[TrueBrain]

Motivation / Problem

When you move the mouse quickly, you can make it disappear. The 60fps patch made this more obvious, but it has always been there. Now, especially if you run 60Hz displays, this becomes nearly impossible to play the game.

I think the presented solution is shitty, as we have no clue why this is happening. It fully works around the problem.
But it does solve the issue and makes the game a lot more playable, with seemly no regression in terms of performance.

So I am PRing this anyway, in the hope this triggers someone else in saying: dude, you are doing NNN wrong. Or that we just accept reality, and go for a proper-functional game :)

Description

When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.

Examples of this are:
- pause the game, move your mouse to the left, and at the right
  speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
  lagging behind.
- in title screen, moving your mouse gives you the idea it is
  jumping places, instead of smooth movements.

In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.

What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.

And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.

Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[TrueBrain]

Also addresses the initial forum thread linked in #7006 (just to create the reference).