* ToolpathProcessors now handles different kinds of tasks (Milling, Cutting, ...)
* all settings in GCodeParameters are moved to the proper ParameterGroup
* for now we ignore the PostProcessors (different GCode dialects)
* show/hide does not work currently for "spindle_enable"
* settings are currently not applied - just the UI works
* still no GCode export

* proper teardown
* selective show for input controls
* use ".get_widget()" instead of the internal ".widget" property

Use a separate function (get_non_conflicting_name) for determining the
name of new objects (models, processes, bounds, tasks and toolpaths).

* TaskTypeMilling returns a tuple of (moves, parameters) - instead of a
  complete Toolpath instance
* ToolpathCrop uses the Crop filter instead of the object methods for cropping
* ToolpathGrid uses the Copy filter instead of just calling "list(..)"
* ToolpathCrop and ToolpathGrid use "add_new" instead of "append" for new
  Toolpaths

* unify the handling of models, tools, processes, tasks and (finally) toolpaths
* this required a change of the interfaces of
  pycam.Plugins.ObjectWithAttributes and pycam.Toolpath.Toolpath
  (use only named parameters - otherwise multiple inheritence fails)
* turn Toolpath.path into a property - now we can detect changes and clear the
  cache
* remove the Toolpath methods copy/crop/get_cropped_copy - now you can
  use the filter instead:
    toolpath | pycam.Toolpath.Filters.Crop(polygons)
* simplified the toolpath plugin - now the implementation is similar to
  models/tools/processes/tasks (no more information storage in gtk models)

* MovesOnly: useful for determining if a toolpath is empty/useless
* Copy: just hide the interal structure of a toolpath (tuple/list)

* duplicate code removed
* marked as gtk-specific

* skip move to safety height if we go straight down afterwards

* additional TimeLimit filter
* read feedrate and safety height from configured toolpath filters

* 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.