OS X adds this "process serial number" argument automatically when launching an
App or similar situations. We don't care about this argument and drop it before
parsing the args using argparse.

Modify regexps and remove ; filtering

When getting rid of the gcode line number (N**), we were not switching command
string to uppercase.

This might speed up Pronterface while printing.
Indeed, as we keep adding items we keep expanding the list and Python has to
move it all the time.

deque is much better fitted than a simple Python list
Indeed, a standard Python list is stored as an array, and has to be reallocated
all the time, while a deque has very fast operation on both ends, and the fixed
size mode will automatically drop first element when pushing to a full deque.
Also it was crazy to store the whole log. Storing 10000 log lines seems decent
and shouldn't take way too much space (less than 512KB based on a quick
estimation).
This might fix #292 and #353.

This change is free as I already changed this string before pushing :)

This also matters as those actual layers are what we will use for ETA

This change needs testing : M114 is unbuffered, and thus might break lookahead
for Marlin and results in laggy jogging. We need to see how bad this is and
find some smart way to do it (like to send the M114 only when the user stopped
clicking everywhere, by using some timer callbacks).

This is a first step towards using gcoder.GCode as a storage for print-time
gcode. Now all we need is a "gcode line id => (layer id, in-layer line id)"
mapping to be able to do the indirection.

This should parse parentheses correctly and handle (valid) gcodes such as
G1X2Y3, while before we were assuming spaces between tokens (which is wrong as
per the G-Code spec). This should fix req #333 in a clean and systematic way.
This is also a component for #343 (Marlin M114 response is in the form ok C:
X11Y22Z33E44, which we can parse with the same expression).

Compute the max of all total lengths

The computed duration is no more pessimistic, for a few reasons.
- the main one is that it does not take retraction into account
- Z moves are not taken into account either
- arcs are not supported
- the acceleration code seems to estimate acceleration time correctly but is
  wrong for deceleration
So instead of telling the user this estimation is pessimistic, let's just tell
them this is an estimate.