[3.2.12] Filein/fileout need to behave correctly in the presence of Characters [128..254] and [255+]

[LisaAlmarode]

Filein and fileout both need to be aware of characters over 127 and handle them correctly (for some value of correct). There are issues, although details are not resolved since both unix and jadeite/dolphin are prone to lying about extended characters.

Given a method such as

method: ClassWithIVs
allCharacters
^ '( ) * +  - / 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G
H I J K L M N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f
g h i j k l m n o p q r s t u v w x y z { | } ~   ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª
« ¬ ­ ® ¯ ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ À Á Â Ã Ä Å Æ Ç È É
Ê Ë Ì Í Î Ï Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß à á â ã ä å æ
ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ  ı Ł ł Œ œ Š š '
%

When loaded via topaz into the image and viewed in Jadeite, it displays like this:

Fileout from Jadeite is garbled, but writing to the project creates (what look like) correct results

---

Filing in from Jadeite however looks like this:

Fileout from Jadeite looks pretty good, but writing to the project, the source is garbled.

---

We do not need full support for filein/fileout of extended characters, but we do need to make sure we can avoid corruption introduced during filein; if nothing else, make it an error to attempt to filein (or fileout?) code with extended characters. The filein/out can still be done in topaz and the display is (holding nose) reasonable.

[ericwinger]

This is on hold pending resolution of GsFileIn does not handle utf8 files