Consider making scipy dependency optional

[yaqwsx]

Thank you for the library! In your Readme you specify that the Scipy dependency is optional (as you use only scipy.integrate.quad and you have a fallback implementation). Also, if I understand your code, it is only needed to implement the length of a path. However, in your setup.py, you specify the Scipy dependency as a hard dependency. Scipy pulls 64 MB of dependencies, which is in a lot of scenarios inconvenient.

Could you consider specifying Scipy as an extra dependency (i.e., moving it into extras_require in setup.py)? In that case, the users can easily choose to opt-out of this heavy dependency and also install it if they prefer.

[mathandy]

I'm open to this -- scipy used to not be listed in the requirements for this reason. The problem is that without scipy, the Arc.length() and CubicBezier.length() methods take about an entire second to run.

I can lower the default precision (when scipy isn't found) to say LENGTH_ERROR = 1e-8 (from 1e-12). This is easy to do but will likely result in some unittest failures (if those tests are run on a system without scipy).

Would this work for you @yaqwsx?

A better solution would be for us to include an implementation of quadrature similar to that in scipy -- according to the docs they use "a Clenshaw Curtis method which uses Chebyshev moments".

[yaqwsx]

I wasn't aware that usage without scipy is that slow. Now I understand that you push scipy as required dependency. The solution I would welcome the most would be to provide a reasonable implementation of the integration and get rid of scipy completely. However, I understand that it is a non-trivial amount of work.

Having lower precision when running without scipy seems like a good compromise at the moment.