Make error message more accurate
Improve Apple Framework JVM dir checking

Previously, it only tested for NULL. But it didn't actually
check whether the directories in question exist (which at
least on OS X 10.9, and probably also 10.8, they do not).
Fail if java path search finds an Apple framework

One of the ways the launcher attempts to locate a JRE is to look for
where in the PATH the "java" command comes from, including tracing back
through symlinks. Unfortunately, on OS X, this often ends up in the
Java Framework's Commands folder rather than in a proper JRE structure.
Do not try to link to the JVM if JRE path is NULL

It makes no sense to set JAVA_HOME to the result of get_jre_home() if
that function returned null. In that case, we should instead simply fail
to create the Java VM.
Use create_java_vm code on OS X for non-Apple JVMs

Previously, the create_java_vm method excluded the bulk of the logic on
OS X, period, assuming that if we are running on OS X then we will find
and use an Apple JVM only.

However, on newer versions of OS X (particularly on OS X 10.9
Mavericks), all the Apple JVMs are removed by default, and the JavaVM
framework is no longer in place to support them. That is, in
/System/Library/Frameworks/JavaVM.Framework/Versions there is no longer
a '1.6' or '1.5' folder, and instead only 'A' with a 'Current' symlink
to 'A'. So all the logic in set_path_to_apple_JVM fails and the function
fails with a "Could not access Java VM" error.

Since we now return an error code for this situation, we can test for
it, and then continue to the non-Apple-specific logic in that case,
rather than always falling back to system Java.
Respect JAVA_HOME on OS X

If the call to set_path_to_apple_JVM succeeds (i.e., returns 0), that
means we found an Apple JVM. But when JAVA_HOME is set, we do not *want*
that Apple Framework JVM to be used, but rather would prefer to use the
JVM indicated by JAVA_HOME.

So let's make set_path_to_apple_JVM return a failure code if JAVA_HOME
is set, so that we can proceed with the non-Apple-specific JVM logic.
Fall back to Apple Framework if no JAVA_HOME given

This change addresses the following situation:

* A newer OS X (without Versions/1.6 or Versions/1.5 present)
* With OpenJDK 7 as the default java executable
* Apple Java 6 also installed (i.e., Versions/A is present)
* And no JAVA_HOME set (via --java-home or otherwise)

In this situation, the behavior had been that Apple Java 6 would be
used, via an immediate call to JNI_CreateJavaVM without setting
JAVA_JVM_VERSION first and without any additional wrangling. But with
the recent change to set_path_to_apple_JVM ("Use create_java_vm code on
OS X for non-Apple JVMs"), the behavior changed so that OpenJDK 7 (i.e.,
the java executable on the PATH) would be used by default instead, and
linked via the platform-independent code that uses dlopen and dlsym
instead of Apple's JAVA_JVM_VERSION with Apple's JNI_CreateJavaVM.

This change restores the old behavior of using Apple Java 6 by default
in this situation. The reason is two-fold: first, it preserves backwards
compatibility, of course. But even more importantly, without this
change, there is actually *no way* of telling the launcher to use
Apple Java 6 at all (since setting JAVA_HOME to the Java 6 directory
actually does not work the way the case logic is currently structured).

Of course, it would be nice to support JAVA_HOME pointing to an Apple
version of Java, but right now, the code is not smart enough to figure
out whether the JRE pointed to by JAVA_HOME is an Apple one or an
OpenJDK one. So for the time being, using Apple's Java by default in
these sorts of cases is hopefully an acceptable workaround.
Add TODO for possible Retrotranslator-related bug