Additional math layout backend

[poke1024]

This is a rather large change aimed at the Jupyter kernel that, as far as I can tell now, fixes all remaining problems pertaining to 2D output with Jupyter.

Specifically, it fixes the output of Text[] and Plot[], which were broken even with the mglyph approach, as mglyph does not support foreignObjects in SVGs.

This PR also introduces methods that could be called from the classic Mathics kernel for some functionality like better text rendering or Rasterize[].

Basically, this adds a node.js server that runs mathjax (and other useful web engine stuff). This server is automatically started (and terminated) as a subprocess from the Mathics kernel. Using this, Mathics can then render any formula or text into SVG. Not only does this allow the exact computation of the extents and formatting (e.g. centering) of the text, but as we only output SVG, Jupyter does not have to deal with any MathML anymore (and no custom JavaScript therefore to fix things up in the browser). It just outputs preformatted, perfectly layouted SVG.

I investigated two other approaches to achieve this, namely:

(1) make all this happen in the browser using WebSockets, i.e. make the client browser render math through MathJax and send back the data to the server. With the classic Mathics kernel, this can be achieved using Django channels, and I got it running, but it's convoluted as it uses a couple of threads and so akin to deadlocks if any of the underlying socket implementation changed (for the general idea, see https://github.com/poke1024/Mathics/tree/websockets); Django channels are cool. For Jupyter, I tried to use the comm interface for the same thing, but Jupyter expects reponses to by synchrononous and it deadlocks if a kernel wants to interact with the browser before responding (for the general idea, see https://github.com/poke1024/IMathics/tree/sockets).

(2) use a headless WebKit browser through PyQT or PySide. I didn't manage to install PySide under Python 3.5 (only 3.4 is supported) and I figured it would need two processes as well, since one process solutions don't work (see https://github.com/niwinz/phantompy). So, evaluating between a client-server solution using PySide or node.js, I figured node.js is not worse than PySide in terms of bulkiness.

The actual node.js server implementation is really small (44 lines of code currently).

[poke1024]

A simple way to test this whole Jupyter thing in action is Docker, see mathics/IMathics#12

[poke1024]

Playing around with this and thinking about it more, I now think node.js is the wrong solution. I'll try to redo this using a Python server backend, handling the communcation via multiprocessing (https://docs.python.org/2/library/multiprocessing.html). This should be way easier to configure, as, usually, it will be one Python environment for all processes, and even more robust in terms of runtime reliability.

[poke1024]

Turns out the QT approach wasn't a good idea, and the current node.js approach is much easier, shorter, and more robust. The QT version server is convoluted, quite long, and crashes on every second run, as it's hard to tear down everything correctly. It's also hard to get the messaging right, as several signals and threads are involved. I'll post this in a repo for reference, but am finishing up work on this node.js version now. It works nicely on Jupyter and classic Mathics now.

[poke1024]

continued in #635