Draft for reading configuration from config files

[rPraml]

This could be a first draft for #1720

[gbrail]

I think that this approach makes sense in that it lets configuration come from the environment, system properties, file, or classpath. I think that's a good thing and that we should follow this pattern.

For actually checking the setting of various flags, however, I think that the config class should parse all this input and set boolean (or enum) values that can be checked directly, rather than relying on a hash lookup. I think that can give us two advantages:

1. It keeps all the logic about naming and renaming things in one place
2. It will be faster, since many of these properties, like the various debug flags, will be checked many millions of times potentially while Rhino runs, and all those hash table lookups will dominate performance pretty soon.

[rPraml]

I think I can implement this next week or so...

[gbrail]

If you're looking for the kinds of debug flags I'd like to potentially replace with a real debugging mechanism, I would look at these:

rhino/rhino/src/main/java/org/mozilla/javascript/Token.java

Line 27 in 3e899f6

public static final boolean printTrees = false;

rhino/rhino/src/main/java/org/mozilla/classfile/ClassFileWriter.java

Line 4476 in 3e899f6

private static final boolean DEBUGSTACK = false;

rhino/rhino/src/main/java/org/mozilla/javascript/optimizer/DefaultLinker.java

Line 25 in 3e899f6

static final boolean DEBUG;

And as for feature flags, the first one IMO should be for the reflect and proxy support that's currently languishing in a PR by @rbri

[rPraml]

Unfortunately, I didn't have as much time as I thought, but I wanted to update the draft before Christmas of how I want to do it now.

The idea is, to check all sources (classpath, configfile, system-properties, env - the last one wins) for the settings and parse them immediately in the correct datatype. When a variable is bound to the property rhino.debugLinker for example. I try to check also the upper-camel RHINO_DEBUG_LINKER version.

@gbrail I hope, this goes in the right direction... Unfortunately (or fortunately) I won't be able to continue until next year due to vacation. :)