Feature #989

Currently, TXM must be installed in an environment where Java is already installed.

This has several drawbacks:
* users must install a compatible Java themselves and it can be difficult to do (find it on the web, choose the right architecture 32/64-bit, the right version, some vendors like Apple sometime change their policy with respect to Java, sometimes there are temporary security risks for some versions or libraries, etc.), adding difficulties globally to run TXM on a machine
* this adds another component to the already big list of independant installations needed to run TXM on a machine (Java, TreeTagger software, TreeTagger models, TXM setup) resulting in a long and error prone installation process and not very practical for users (the ideal scenario for a software installation process is to launch just one installer software and that the installation process is the most automatic)
* if different Java versions can run TXM in a given environment we have the risk that TXM behavior can be different between them (typically at the borderline of the Java language specification - preemptive threads, etc. - or different versions of hosted Java libraries), and this can be very difficult to support and maintain from the point of view of TXM
* last but not least, Java suffers from its reputation of slowness and security risk in browser applets. Putting Java less in the front would help users to concentrate more on the right components for performance issues (like CQP search engine for example which is not written in Java) and not be needlessly alarmed about security risks (TXM execution context is not in an applet).

Embedding a JRE in TXM will greatly simplify TXM users and developers life.