This reverts commit a6fac6a.

This start changing all defined methods to use the raw (8859_1) string as the
key in the method table.  Symbol StringLiteral both now properly use proper
ByteList and does not muck with String.

… twice.

…l name.

Guard against it since it is a normal value.

…859_1 or

a raw string.  So I made toString() decode to actual charset based on encoding.
This may need another field if we discover toString() on RubySymbol is called
all the time but let's roll with this made on-demand for now.

Make and/or use isOr/isAnd and leverage AST being able to tell us this vs
  manually figuring it out.

```text
jruby -e 'p method(def foo(あ); end).parameters'
[[:req, :あ]]
```

to work.  Up til now this would confuse our impl and we may see an error like:

```text
ArgumentError: invalid byte sequence in US-ASCII
  inspect at org/jruby/RubySymbol.java:283
  inspect at org/jruby/RubySymbol.java:268
  inspect at org/jruby/RubyArray.java:1659
  inspect at org/jruby/RubyArray.java:1659
        p at org/jruby/RubyKernel.java:492
   <main> at -e:1
```

Pure ruby code should not properly be giving properly encoded values back. Java
(e.g. native) methods mostly should not matter since they do not return names
but if they do return names then they are all assumed to be UTF-8 encoded data.

…re number.

…field

name but name changed from a String to a ByteList which make new frame read
write code find nothing.

…nkle in

our strategy.  Errors are generated from the search deep in Module but it is a
raw String.  This is somewhat ok for most strings because they just happen to be
utf-8 so the display.  This is a big issue though since we want proper error
message....

… day

would come but I was hoping I could cheat with 8859_1 strings enough to merge
for 9.2.  Unfortunately, lack of encoding through method methods means we cannot
accurately throw properly encoded error messages since he have long lost the
encoding of the method.

So with that said, most people will not be able to notice this change.  All the
String methods for methods still exist.  These methods will assume all data is
UTF-8.  This could be a dicey gamble but since it is the default for Ruby it
likely will not impact anyone.  Also since UTF-8 is 7bit clean for ASCII we
should totally not have an issue there.

Some API signatures have changed.  This means 9.2 might end up causing some
issues if you are doing something very low-level with our code base (although
changes up to this point have already broken some APIs within parsing and IR
and that is unavoidable).  The method reader/writer maps needed their return
type changed from <String, DynamicMethod> to <ByteList, DynamicMethod>.  It
was an option to make a new name for methods which returned this but this is
so far down in our APIs I think we should run with it.  Also ProfiledMethod
has changed from String to ByteList (e.g. getName() -> ByteList from String).
Ultimately ProfiledMethod needs to be properly encoded to be able to report
the method in a properly encoded way...so there you have it.

Next phase is to change interpreters and the JIT to stop from going:
ByteList -> String -> ByteList.  I did not do that part here since this is
pretty large already.

…mmit is

a little off in that it assumes the String returned from the properly encoded
symbol will be the same encoding as the String returned.  Generally this will
be UTF-8 so it will almost always work.  Not perfect but better.

…r first

and last character to see if it is a local variable.

In truth, this is pretty weird code.  IdUtils only works with String and without
doubling the code for ByteList there is a weakness since non Java Charset
strings will not work here.  IdUtils itself is also pretty weird since we really
just want variables which are not special and this method checks for all sorts
of things we know these strings can never be.  (FIXME: added)

require_relative implementation.

…is saved

somewhere!

As systemic insulating design choice all identifiers are forced to construct
an eager RubySymbol as constructor argument to the AST (note: parsing and IR
APIs definitely are not backwards compat with 9.1).  This should future-
proof things.  By forcing the AST to use symbols it means we cannot make idents
which are not eager in making a symbol table entry.  This in turn means later
on when we work with the raw string equivalent of these idents....we know there
will be a symbol table entry.  As an aside MRI is eager on all idents/symbols
so we are being a little more like them (which is not semantically important
but who knows?).

Constants, ivars, gvar, cvars all made to use raw strings.  This still has some
fallout to deal with. For example const_get? will use the string and assume it
can charAt but it cannot since it is now a raw string.  In cases like this
we need to ask for properly encoded bytelist and perform same logic but in a
mbc friendly way. This will likely be the next commit(s).

Tons of error reporting corrections (with tons more needed).  Now that all
identifiers are raw strings they look weird when they contain mbcs.  So I added
a buildString which makes a RubyString which will do proper m17n stuff to make
a byte coherent string.  I did many of these when I see them fail in the test
suite but the pure lack of coverage in this regard is staggering.  My hope to
limit an endless stream of reports is to lean on all errors which refer to
idents using the same helper method as a visual cue that it will be properly
handled.  Both this and the symbols in AST constructors are meant to help us
at a glance not make an error or know why we have an error at a glance.

All-in-all this last dump has had me work through many issues and I am still
pretty happy.  Making older extensions continue to work has added a tough
dimension but so far so good :)

$_foo would not ever parse....

…o how MRI

works.  We do not want them going away since we may no longer have a reference
in the AST nor IR (actually IR does not store symbols at all but even if it did
I would like persistence to play a future role so we can save long uncalled or
already JITd IR to save memory).

const_defined? totally changed and only broken now due to missing proper logic
for printing out type names in error messages.  Outstanding is if the string
contains something the encoding thinks is unprintable it will display the type
in quotes and escape the unprintable character.  dumpString is nearly correct
but it will not correctly pick up \u0000 for \0 but instead print out \x00.

Landing for now since this is again a bigish delta and it advances things a bit
more.

- new ids() method for an 'ID String'
- Realization that any types reported in Ruby should call to_s ALWAYS if it
  has been defined.  We have a number of paths which will rely on name and
  baseName (rubyName and rubyBaseName).  I am still working through
  ramifications of this but toRubyString was added.  This site calls to_s
  and returns the string.  For types this will eventually either to_s on
  and overridden method OR it will fall back to calling rubyName (which will
  use a cached name it calculated once).  Not finished updating.

Just making a cleaner slate for now.  There is only 2 errors left in test:mri
but I think there is really poor coverage on m17n+error strings.

…nt something here valid as a default name even if we explicitly add nil as explicit param to constructor.

…me silly

mistakes.

IRubyObject.

…entifiers

are ridiculously accepting of ALL non-ascii codepoints.

…er printing

or types and non-types for error strings.