Made some changes to improve stability when using higher values for TOLERANCE:
	* The Poly::split function now recognizes the possiblity that the split may result in two identical polygons or one polygon which is a subset of the other; it will abort the split and return (nullptr, nullpt) in this case
	* the Point3d::perturb function now perturbs by TOLERANCE * 10.  It's occurred to be that perturbing by exactly TOLERANCE isn't safe because I use the >= and <= operators instead of < and > when doing floating point comparisons against TOLERANCE	*
	* It's still not safe to use tolerances greater than 0.001 yet, as the system can get stuck in an endless perturb loop.  This can be solved by increasing the scale in the Point3d::pertub function, but I'm not sure this is the solution; increasing TOLERANCE should increase the amount by which we perturb, so I can't explain why these endless perturb loops can happen
	* Higher tolerances are also prone to small gaps in the geometry (which may be explained by the area of the gaps being less than or equal to TOLERANCE in which case nothing is wrong) and missing polygons (in which case something is definitely wrong).

	* The important part, though, is that I've finally fixed the problem of endless loops in the Object::splitBy function with large values of TOLERANCE.  I've been trying to figure out why this happens since April 2012 0_o

I've also fixed a minor bug in Object::classifyPoly:
	* In the case where the ray originates in polygon B's plane but not within polygon B, we now give up and move on to the next polygon because this polygon B most certainly is not intersected by the ray.  Previously, we did a perturb and retry, which is not correct

Additionally, I have added an operator<< overload for Point3d.