Re: \u escapes in string literals: proof of concept implementation

This is the third version of my patch for \u escapes.  It is stronger 
than the first and cleaner than the second.  I'm more confident about 
this one.  If \u escapes are still desired for 1.9 (and I hope they are) 
I think this patch will be helpful.  Someone with more experience with 
parse.y needs to look it over carefully, but I don't think it is a 
complete hack, either.

The patch includes two different sets of code for converting codepoints 
to UTF-8.  The shorter one relies on enc/utf-8.c  The longer one does 
the conversion explicitly and is probably a little faster.  But I've 
commented it out in favor of not duplicating that conversion code.

The patch is attached.  This is some interesting test code that you can 
run if you apply the patch:

# \u escapes work in these forms
puts "\ubbbb"
puts %Q{\ubbbb}
puts %W{\ubbbb}
puts <<EOS
\ubbbb
EOS

# \u escapes don't work in these forms
puts '\ubbbb'
puts %q{\ubbbb}
puts %w{\ubbbb}
puts <<'EOS'
\ubbbb
EOS

# \u escapes work in regexps
puts /\ubbbb/

# \u escapes in regexps are handled by the lexer, but
# all other regexp escapes are handled by regexp engine
# This leads to possibly confusing behavior, since a \u005c
# is converted by the lexer to \, and the regexp engine can
# then interpret it as an esscape
puts /\u{5c}(/    # match a single open parenthesis

# Here is the other form of \u escape
puts "\u{41}"       # Letter A
puts "\u{A0A}"      # Some greek thing?
puts "\u{10FFFF}"   # Largest Unicode codepoint

# Encoding stuff.  Any \u escapes for codepoints >= 128
# always force utf-8 encoding.
puts "\u0079".encoding   # ASCII, regardless of -K
puts "\u0080".encoding   # UTF-8, regardless of -K option
puts "\x79".encoding     # ASCII, regardless of -K
puts "\x80".encoding     # encoding depends on -K