* implement toolpath cropping via a filter
* highlighted warning label in toolpath cropping UI dialog
* filters gain a "clone" method (this allows deep copies of toolpaths)
* MachineSetting filter preserves the order of settings (before: last in first out)

* don't forget to close polygons (if the ancestor was closed, as well)
* take direction of offset into account before skipping small polygons
  (growing is always allowed - shrinking is limited)

Toolpaths ("moves") are now created as simple lists containing a tuple
of two values:
- a type identifier (numeric constant) - e.g. "move", "move rapid", "safety move"
- arguments (can be a tuple, as well)

This structure allows the use of "filters" for GCode generation.
A simple example:
A "laser" GCode generator will turn all "safety move" items into
"laser power on" and "laser power off" respectively.
A milling machine GCode generator will turn all "safety move" items into
rapid moves up, then sideways moves and then slow moves down to the next
destination.

Currently the following filters are implemented:
- skip a safety move if a short sideways move does no harm (e.g. zigzag mode)
- replace safety moves with the proper combination of normal and rapid moves
- a simple example filter for machine settings (feedrate, metric system, ...)
Tool change and touch off, as well as the missing startup settings are still
open.

The "decimal" module can cause the output of values like "0E-12"
with the "%s" formatting string.

Test case:
   import decimal; print decimal.Decimal("0.0000001")
=> 1E-7

This fix uses a "%.?f" (? = number of digits) format string based
the number of significant digits as given via "minimum step width"
in GCode settings.

1) There was a piece of code that erroneously closed polygons.
2) Inside polygon culling was falsly catching open polygons. At best this code needs to be rewritten to correctly detect inside polygons.

Whitham D. Reeve II

Original developer left out a condition in a trailing else to generate an additional line to close a polyline when specified.

Made changes to remove consecutive duplicate points, combined two loops that iterated through points into one.

This code commits draw_direction_cone_mesh which is an adaptation of draw_direction_cone to generate a mesh of triangles for compression inside a vertex buffer object. The rest of the opengl code in Toolpath has been changed to use this. Only remaining use of old rendering path way is simulation.

Whitham D. Reeve II

Profiler suggests that the min/max functions for x/y/z of the Toolpath object were the main bottleneck. They iterate through all the points in each path every time they are accessed. These values are now cached which provides a huge speed boost. Originally I thought the problem was the opengl drawing code so I created a new code path that converts moves into an arrays of vertices and indices. The vertices array particularly is stored in video memory. While faster, I don't think it is all that much faster.

Whitham D. Reeve II

PyCam has been spending about 75% of it's time creating point objects. I decided to replace
the pycam Point object with a 3 position tuple, and the pycam Vector object with a 4 position tuple.

All of the point object methods were rewritten to accept and emit tuples. The transform_by_matrix method
was rewritten to accept both 3 and 4 position tuples with behavior dependent on that size. The
normalized method is the only method required to emit the same kind of object that it is called on, and
this has been taken care of with the tuple version.

What does this mean?
All instances of Point(x,y,z) have been converted into (x,y,z)
All instances of Vector(x,y,z) have been converted into (x,y,z,'v')
The notation to access the x,y,z of the Point objects has been been changed
	from p.x,p.y,p.z to p[0],p[1],p[2]
The notation for the point math functions has been completely changed.
Instead of p1.sub(p2) it has been converted to psub(p1,p2)
Instead of p1.sub(p2).mul(0.5) it has been converted to pmul(psub(p1,p2), 0.5)

It is very important to point out that the tuple is an immutable type.
You can not change it once you create it.
t[0] = calculated_x_value # syntax error
You have to replace the reference (t) to the old tuple with a new reference to a new tuple.
t = (calculated_x_value, t[1], t[2]) # works

There was a particularly hairy mutable/immutable barrier in the next() generator present in each class that
inherits TransformableContainer. The TransformableContainer.transform_by_matrix function uses these
generators to collapse polygons and lines and triangles into points where a shift is performed on each.
Now that point is immutable, you can not change the value emitted by the generator.
Geometry/__init__.py transform_by_marix and the associated next() generator in each sub class has been
rewritten to transfer the attr used to store the reference to the tuple.
Geometry/__init__.py transform_by_matrix now sets these attributes which effectively gets around this
limitation.

There could be some old point object code in any of the files not contained in this commit.
It is impossible to know without running the code path and/or careful analysis of each file.

Some list comprehensions that convert a list of point objects into a 3 position tuple have been removed.

Whitham D. Reeve II

PyCAM currently shells out to inkscape and pstoedit to read SVG files -
without those helper programs, pycam cannot read SVGs.

The pycam debian package currently Suggests those dependencies, which
means that by default (unless the user explicitly selects them) they
won't be installed.

This commit upgrades the relationship from Suggests to Recommends,
so they'll be installed by default, making SVG work "out of the box".