Print useful error messages, instead of cryptic exception traces,
in three cases of "java.so -jar something.jar":

 1. When something.jar doesn't exist
 2. When something.jar exists, but can't be read as a jar (zip) file
 3. When something.jar exists, but doesn't have a "Main-Class" field
    in its manifest.

Starting the CLI and using the run command by specifying it as a run.py argument
didn't work due to a cast problem (run expected NativeArray).

previousely this didn't work:

$ sudo ./scripts/run.py -n -e "java.so -jar /java/cli.jar run tools/netserver-osv -D -4 -f -N" -c2 -m1G

This single Java source file is a full-fledged HTTP 0.9 server.
I wanted to add it to expose the console lock bug (fixed in a separate
patch), and to verify that bind() works correctly (it does).

But additionally, this tiny HTTP server (about 6KB of compressed bytecode)
can be very useful for our CLI - it can be run in the background and let
you view files in the OSV system in your browser, even while another
program is running.

To run Shrew from the CLI, just run

	java com.cloudius.cli.util.Shrew

Which runs the HTTP server in the background (in a separate thread),
letting the user continue to use the CLI. If you add an argument "fg" to
this command, it runs the server in the current thread, never returning.

Currently, the HTTP server is written to browse OSV's root directory
hierarchy: accessing http://192.168.122.100:8080/ from the host shows
you the OSV guest's root directory, and you can decend into more
directories and download individual files.

Exposes tracepoints and counters

The recent change, to add the program name as argv[0] for C code's
main(), make sense for C code, but less for Java code, where main()
normally expects args[0] to be the first argument, not the program name.

So the change to RunJava.java was un-Java-like; It also broke the "java"
CLI command which didn't put "java" in argv[0] for the arguments to
RunJava.main(), so the "java" command no longer worked after the previous
patch.

Instead, we change java.cc (which compiles to java.so). This is what
calls RunJava.class, and it should remove the new argv[0] before calling its
main() - instead of expecting that RunJava.class to do this.

the convention in linux is that argv[0] holds the program executable.
I had an attempt to run netserver not from the CLI and it didn't work because
its argument parsing got broken.

Added the possibility to pass to cli.jar a command, which it runs instead
of taking commands interactively. Note that the initialization script is
run before the given command.

After this patch,

        scripts/run.py -e "java.so -jar /java/cli.jar"

Continues to run the interactive command line editor loop, as before.
But additionally, one can do:

        scripts/run.py -e "java.so -jar /java/cli.jar ls"

To run just the command "ls" and exit - exactly as if the user would type
this command on the command line and exit the VM.

The given command can be, of course, much longer. For example to run Jetty
after the CLI's normal initialization script, the following monster can
be used:

scripts/run.py -n -e "java.so -jar /java/cli.jar java -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration /jetty/jetty.xml"

(Funny how a single command should say "java" 3 times and "jetty" 4 times :-))

java.cc would exit right after the main() method finished. But in Java,
this is not the correct behavior. Rather, even if main() returns, we
need to wait for all other threads to end (or more accurately, wait
for all threads not marked with setDaemon(true)).

Calling jvm->DestroyJavaVM() does this for us, and it's probably the
Right Thing(TM) to do anyway.

Before this patch, the Jetty benchmark exited immediately after
startup.  After this patch, its worker threads keep the whole VM running.

Java.so used to correctly support the "-jar" option, but did not fully
allow the other "mode" of running Java: specifying a class name which is
supposed to be searched in the class path. The biggest problem was that
it only know to find class files, but not a class inside a jar in the class
path - even if the classpath was correctly set.

Unfortunately, fixing this C code was impossible, as JNI's FindClass()
simply doesn't know to look in Jars.

So this patch overhauls java.so: Java.so now only runs a fixed class,
/java/RunJava.class. This class, in turn, is the one that parses the
command line arguments, sets the class path, finds the jar or class to
run, etc.. The code is now much easier to understand, and actually works
as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
benchmarks, which forced us to tweak the class path manually.

The new code supports running a class from the classpath, and also the
"-classpath" option to set the class path. Like the "java" command line
tool in Linux, this one also recognizes wildcard classpaths. For example,
to run Jetty, whose code is in a dozen jars in /jetty, one can do:

        run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"

the new test creates several thread, each is downloading a ~280MB file
concurrently. It aims to find concurrency bugs in the netport, dead locks,
etc... but (fortunately) it pass.

making it even more stressful ;)

now it downloads a ~200MB file and validating md5 on it.

As Nadav found out, we don't have to call defineClass and register each visible
Java class within the js scope, this makes it much simpler to integrate with Java
from the cli.

Not provided by the musl headers, and also unneeded.

Until now, OSV's console defaulted to raw mode, to make the CLI
happy. The problem is that on Linux, applications expect to be
run in cooked mode, so if we ever run a simple application that
tries to read user input, it can be confused.

This patch makes OSV console default to cooked mode, and the
CLI switch to raw mode before reading an input line - and reset
to the default mode just before running the user's command.

Unfortunately, we had to resort to adding a JNI class "Stty",
since Java has no builtin support for the ioctls required for
changing the tty settings.

uses Java nio.* for downloading a file, writing it to /tmp

requires starting qemu with tap networking, first install libvirt
then launch the run script as root with the -n option.

Example:

$ sudo ./scripts/run.py -d -n

in osv you'll have to configure networking as follows:

$ ifconfig virtio-net0 192.168.122.100 netmask 255.255.255.0 up
$ route add default gw 192.168.122.1

SPECjvm2008, uses the Thread.getContextClassLoader() class loader
to load classes - instead of using the current class-loader as any
decent code does when using reflection.

To allow this ugly, but officially supported, usage, we need to
set the context class loader in RunJar.java.

eventually causing a suspicious segfault.

class-static variable, which is not only strange, it also means we
cannot concurrently run several programs in several threads.

Change it so run() returns the (32-bit) return value, and when execution
fails (e.g., file not found), it throws an IOException.

Note that unlike Unix where main()'s return value is limited to 8 bits,
here we decided to allow the full gamut (63-bit) of return values from
main(). main() may return -23 or 2323813 and this does not indicate
an error running it (only an exception indicates an error).

This patch also removes the arbitrary limit of 256 command line arguments
(not that anyone would need more...).

All Java tests need to implement the Test interface and be registered with
TestRunner in order to be available to the test cli command.

TCPEchoServerTest is no longer accessible from javascript, instead, TestRunner is
now the interface of JS for running tests.

note: this class is not yet used by the CLI and will be used in a following
patch

split cloudius.jar to cloudius.jar an cli.jar
the following patch will introduce proper code reusing between the two jars
basically, cli.jar will be dependant on cloudius.jar