Windows codepages do not have C1 controls

MS CP125X do NOT actually have any high control characters, the MS tables
show some of them but they are never interpreted by Microsoft software
and, as they have done before, MS will replace them by any new characters
that may be useful in the future.

Also eliminates as possible security risk where control characters are
not expected in Windows csets by host software.
Fix the scoasc translation on unix

There should be a set of VGA ROM characters in the first 32 positions
of the character set to match with Linux, scoansi and Windows PuTTY.
Function x11font_draw_text uses the UCS2 character set

Bugfix to stop the character set being repeated above U+10000
SCO Ansi Keyboard correction

The centre key (the '5') of the number pad should generate a CSI E for SCO.
Correct Window title character set on windows.

The characters are converted to unicode before use.
Changes to the internal usage of unicode areas for character set conversion.

The unix port is using the U+D800 range for the same jobs as the windows
port uses the U+F100 range. Set it to use the same range of characters.

Note: unlike windows this is ONLY used if the font doesn't have a
recognised character set so this change doesn't make the DTF range
compatible with the Linux console.

In a similar issue terminal.c is using the CSET_* codes for two different
tasks; the screen map characters and the line characters. Making the
distinction explicit should clarify things.

We now have a 32bit space for the characters so the hack of placing
the CSET_* code overlapping the surrogates is no longer required. We
can instead place them past the end of the valid unicode characters
(ie U+180000). Note I've chosen 0x180000 rather than 0x200000 to preserve
the compression of the scrollback.

Unfortunatly I can't do the same for the DTF range as it wouldn't work
for the UTF-16 platform. I can, however, move it to the "Low Surrogates"
area where it shouldn't interfere with the normal use of surrogates.

Added Linux DTF range (U+F000 -> CP437) explicitly into the emulation
because we no longer have the "happy coincidence" of the OEMCP being
mapped to U+F000. This means it could now be disabled for pure utf8 mode.
Clean up VT52 leftovers from the 256 colours patch

Some references to the unused flag vt52_bold are removed.

Remove the messing with the 'blink_is_real' flag as it's no longer
needed for the Atari colours now the flag no longer overlaps with the
bright background.

Add the MiNT blink codes now the the flag will work.

Also, the wrap mode should be set to "2" for Atari compatibility.
Add wcwidth override sequence

ECMA-48: 8.3.90 PEC - PRESENTATION EXPAND OR CONTRACT

CSI Pn SP Z used for character width override.
	Only applies to characters that are not in US-ASCII.
	Does not work with DBCS fonts, only unicode conversion.

    Pn=0   Default
    Pn=1   Force Wide for unicode chars.
    Pn=2   Force narrow for unicode chars.
    Pn=5   Force one Wide unicode char.
    Pn=6   Force one narrow unicode char.

This allows the host to do a DBCS to UTF-8 conversion and keep the
anachronistic alphabetic artifacts of the original encoding.
XTerm: Add Ansi REP sequence and SCO CSI = g

This gives us the XTerm rep sequence.

ECMA-48: 8.3.103 REP - REPEAT
    Notation: (Pn)
    Representation: CSI Pn 06/02
    Parameter default value: Pn = 1

CSI = Pn g
    Display the number Pn as the character from the selected font.
    For 0..255 this is does as the CP437 VGA ROM set, for 256 and
    above it is a unicode character number. Note: SCO ansi does not
    implement values over 255.

This change requires the literal character print routine to be called
from more than one location so that code has been extracted into a
distinct function. Pragmatically this is a long overdue change to help
reduce the size of the huge term_out function.
Fix width override bug.

Width override should ignore combining characters.
Add DIM, CONCEAL, BGBOLD and Blink control.

CSI 2 m	    Set screen colour to dim
CSI 8 m	    Hide the character printed by making the normal display
	    just the background colour. If the text is selected the
	    text is shown
CSI 6 m	    With the advent of 256 colours the SCO Unix bright background
	    sequence can now be implemented using a distinct flag,
	    it doesn't override the 'blink_is_real' flag.

Also in here is a control to allow the text blinking to use any of the
above styles; this includes both the strident PC style and the more
civilised Wyse style.
Add Linux default attribute set.

This is overrides ECMA-48 SDS.
Included so the effects of CSI=F can be reversed.
Make sure all ISO-2022 codes are checked.

They should all be disabled by 'no_remote_charset' some where missed.
Including the vt52 charset modes.
Timer starvation fix

If the remote (or pty for pterm) is giving us data very quickly it can
stop the timers being called. This makes sure we check the timers even
if we're very busy with characters from the host.

NB: Can no longer reproduce this (test machine upgraded).
Fix WM_NETEVENT delayed processing.

Now the function run_toplevel_callbacks() is only called when there
are no pending messages in the Windows queue. This is how it was
designed to work.

Fixes the bug where large fast streams of data from the host will lock
up PuTTY's windows GUI.

But everything still stops if a dialog box or the config box is running
on a different Despatch loop.
Repair handling of WM_NETEVENT (part 2)

This is a simple attempt to reinstate the timer delayed processing of
WM_NETEVENT messages so that processing can continue when secondary
windows (eg the config box) are displayed.

Needs work; seems to miss sometimes.
Fix support of 256 colour palettes.

PuTTY will now redraw it's window when the system palette changes. In
addition the default colours are now at the start of the palette given
to Windows so it's more likely to choose a good colour when the user is
most interested.

The old method using 'UpdateColors' would mostly work on some devices, on
others it would give a completely corrupted set of screen colours. Even
when it did work if you were using XTerm 256 colour mode it would
be unlikely that the colours would ever return to the correct visual
representation and the errors could even spoil the simple 16 colour
collection. The new method simply does a complete redraw when the palette
changes; this is much more robust in the face of dodgy drivers and means
that the colours will always be as correct as possible.

As it now seems stable I've turned it on by default.
Scramble palette

The 6x6x6 cube is scrambled in the palette given to Windows.
This means that even if Windows only gives us part of it we should
get a good selection of colours.
Windows font drawing change.

I've finally given up on using the hDC returned by BeginPaint.
Instead the BeginPaint/EndPaint pair is used to fetch the invalidated
rectangle and tell Windows that it's been validated.

After that we get a proper DC for the entire window and use that for
all the drawing.

This allows us to always update the screen immediatly during the WM_PAINT
message processing and avoid all the bugs in other applications that seem
to trip us when we assume the clip region that BeginPaint sets up is okay.

The end result is that it appears to be much more reliable.

Note, however, we still have the issue that windows is getting slower.
The proportional font update and the do_paint change should help.
Don't let do_paint eat too much CPU