Don't make 0-length edges through poly_push_vertex

This fails a real-world case at the moment.
poly_push_vertex() now returns bool

This will make other logical tests read easier.

Also, it's 2014.
Test for new poly_push_vertex() behavior
Spell like an adult.
Merge branch 'master' into dont-create-zero-loops
Notes as a I read.
poly_print_with_plane_info() for debugging
poly_classify_vertex_string(.) added.
WIP/HACK/NOISE: poly_split() cannot fail

This alters poly_split() in a way that it cannot "fail" by returning
-1, the new paths allow for polygons to fail vertex pushes, then
continue accumulation, with a noted failure.

Before returning the potential `front` and `back` polys are considered
for validity (if failure was flagged -- for now) and free'd if invalid.

This allows the caller to get back NULL pointers in `**front` and
`**back`, but that case is already handled.
Removed the `failed` flag in `poly_split`

The failed polygon cull is unconditional now.
Merge branch 'master' into dont-create-zero-loops
Stopgap for not crashing on bad data.
More noise for free
Added poly_push_vertex_unsafe

It's made by a refactor of poly_push_vertex -> poly_push_vertex_guarded
and redefining the original and new _unsafe helper as wrappers.
WIP: stl_mesh_t patch check
Stop producing potentially null STL->poly poly_t's
Assert poly count is constant in audit conversion
Format string type error
poly_make_triangle() gets guarded and safe version
stl_mesh->to_polygons(..) provides _unsafe variant.

No built in mechanism to patch it, but you can replace
the function pointers on the fly.