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 locate compatible Apple 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 trying to blindly link to an unspecified and
probably-missing Apple version of 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 create_java_vm ("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