The gauges options is a CLI parameter as having it as an option would be
too painful to handle for now.
Argument parsing has been improved so that pronterface can add its own CLI
parameters in addition to pronsole's ones.

Should fix #348

This reverts commit 02ef52d7.
First step towards getting the gauges optionally back for #296.

This should fix the weird graph background for #359

One of the strings is to give a hint for wrong baudrates (#276)

Should fix #359 initial issues

Conflicts:
	.gitignore
	printrun/gui.py

There is a lot of code duplication between addgcode() and add_parsed_gcode,
which would probably need to be cleaned up.

This might be slightly off, but it could also be the zooming code that's off.

This commit mostly removes unused code and cleans some things up.
The main contribution is that instead of calling repaint() and Refresh(), we
now only mark the canvas as dirty and call Refresh(), which will do the repaint
just-in-time. This speeds things a lot when quickly changing layers or zooming,
as it does not repaint once per keyboard/mouse event but once per actual
Refresh, which makes it much smoother.

FWIW, on my test system with my test GCode loading time goes down from 5.7s to
2.3s between b3a673bc and this commit, that's almost 60% gone.
However, there is still a lot of room for functional improvements :
- I don't think the roundtrip through the target array is useful
- There's no handling of relative coordinates (neither for position nor for e)
- The arcs drawing code might be wrong
- The stlview bits are not enabled and probably have to be looked at and updated

Command line option parsing really needs a better rework, to use optparse or
argparse and support gcode/stl filename argument.

Estimation duration now uses the already parsed GCode instead of reparsing it.
It also computes a per layer duration estimation which can probably be used to
produce better ETAs.

The only difference is that it does not compute duration for Z layers changes,                                                                                                                        but it was probably super wrong already given how it is done (it only changes
the estimation by than 2s over 2 hours of print and 54 layers, and the feedrate
stuff mixes all the axes together).

I also detected a few potential issues in the code, which are marked by FIXMEs.