Premature res.end solved

The problem was that the response object couldn't keep up with `stdout`,
resulting in `res.end()` being called before the `stdout` data was
flushed. I looked into the Node `Stream` source code and hacked into it,
first checking if `stdout` was flushed and if not, listening to
`res.on('drain',...)` and checking again. This solved the problem
beautifully.

The only major problem left is that FreeCAD writes status info to
stdout, intended for a human user. Some of it (like loading status of
file) can be kinda useful, but most of it isn't and is inconvenient for
stdout piping (the recipient receives this too). It's especially bad
when first setting params and then requesting a tessellation, resulting
in the response getting piped before anything else and thus receiving
all bogus. I currently didn't implement any way to know if changing a
parameter finished and don't want to (I assume that commands are sent in
blocks and a response is always required and passed, allowing `generr`
to be emitted on the response object).
Thus I can either listen to the start of a tessellation, or turn
FreeCAD's stdout printing off somehow. The latter is the perfect
solution, the former is very well possible but might (and will)
introduce timing errors (when node is busy, for example, and empties
stdout when there's already useful data available).

The only problem with the current architecture is that `generator.py` is
idling if its `stdout` hasn't been flushed to the `response` object (the
client, recipient, browser). But this won't be a big problem, assuming
that the client connection is always reasonably fast. And this can be
solved relatively easy by buffering `generator.py` `stdout` somehow, if
ever needed.