Added build ("make") framework for compiling Java code we want to run in
OSv (in/with the Java payload), as well as JNI, i.e., OSv-specific C code
we want to run from the above Java code.

The Java source files in java/src/ are now all compiled during build
(see java/build.xml for the Ant file doing this compilation) and the
result is one JAR, build/$mode/java/cloudius.jar (/cloudius.jar in bootfs).
We can easily change build.xml to create more than one if we want.

As an example of JNI, I used the not-working-yet balloon feature.
java/src/com/cloudius/balloon/Balloon.java is the class
com.cloudius.balloon.Balloon which is supposed to have one "native"
(implemented in C) function giveup(). This function's implementation is
in java/jni/balloon.c. We get this file to compile to balloon.so (put
in /usr/lib/jni in the bootfs) by adding java/jni/balloon.so to the
"jni" list in build.mak.

If you don't know how write the ugly function signature as seen in
java/jni/balloon.c, you can run "javah com.cloudius.balloon.Balloon"
to build the empty functions needed for implementing the native functions
defined in the above class.

If a target fails to build, it is probably corrupted.  Delete it.

Fixes misbuild after a second make with an incorrect bootfs.manifest.

Not completely silent unfortunately.

One test so far: java.lang.System.nanoTime()

We're only about 500% slower than native.

-MD accepts no argument, and luckily the argument we supplied evaluated to
nothing.  Remove it.

the -MP switch allows make to ignore deleted files.

this gives us better dependency tracking.

We need different rules for .s (compiled by 'gas') and .S ('gcc') since
the compiler and assembler take different command line options.

It's as arch-specific as they come.

This implementation stores small objects in pools of similar-sized objects,
while large objects are allocated using a first-fit algorithm.  There is also
a specialized interface for allocating aligned pages.

order to reach includes files for within the hirarchy.

No threading yet, so no real locking

This forces the linker to add a DYNAMIC segment, allowing us to export our
symbols to loaded libraries.

This gives us full control over linker options.

We need the headers so we can provide the symbols to loaded libraries.
This means we cannot use objcopy to munge the binary format to elf32-i386,
as the loader doesn't understand this format.

Instead, add a separate 32-bit only stage (in elf32-i386 format) that loads
the 64-bit image into memory as its payload.  This keeps multiboot happy and
leave our headers alone.