THREE.Path.prototype.toShapes: Bugfix; new optional parameter: noHoles

There was a bug: If all subpaths had the same wrong winding order there were only holes and no shape which threw an error. In this case now it's assumed that all these subpaths are in fact solid shapes instead. So the winding order is disregarded in this case.

I added an additional optional parameter "noHoles". If set to true, it forces the same behaviour. All subpaths are regarded as solid shapes. The winding order has no significance. 

This e.g. comes in handy when importing SVG-Paths which sometimes have no consistent winding order (since SVG has the evenodd polygon fill option which doesn't use the winding order). If you know there are no holes you can force the "toShapes" function now to disregard the winding order too.