japanese encoding webkit fixes for 3.0 branch

I wanted to get these changes in for the webkit trunk by persuading the upstream
before we launch 3.0, but I haven't managed to. 

1. Pages labelled correctly with EUC-JP containing 3-byte Kanji characters in
EUC-JP are treated as Shift_JIS. It's because pages labelled with Japanese
encodings (SJIS, EUC-JP,ISO-2022-JP, etc) are ALWAYS subject to the built-in
Japanese encoding detection, which fails in cases like this. 
   
  It's a bad idea to use the encoding detection without a user's consent
especially for pages explicitly labelled (correctly).

   http://crbug.com/3799
   http://bugs.webkit.org/show_bug.cgi?id=21990

2. 0x5C in EUC-JP encoded pages is converted to U+00A5 (Yen sign) instead of
U+005C (back slash). This can be very frustrating to some users because they
lose 'back slash' in EUC-JP encoded pages (copy'n'paste gives them U+00A5
instead of U+005C. Regular expressions, TeX/LaTeX snippets, other escape
sequences in programming languages and CSS cannot be copied and pasted. 'Find in
a Page' does not work, either). Somehow, the symptom is not  reproduced although
the code is still there. It should do no harm to
remove the code that shouldn't be there, though.


   http://crbug.com/9696
   https://bugs.webkit.org/show_bug.cgi?id=24906

One webkit test will fail, but it's harmless.

BUG=3799, 9696
(http://crbug.com/3799 http://crbug.com/9696)
TEST=NONE



Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=24466

[jungshik at Google, 2009-08-26 16:20:03]

Hi Anthony,

I'll check this in in today's meeting with you.