Split JtsSpatialContext etc. to separate module and 'jar'.

[dsmiley]

I was bemoaning the inconvenience in Solr that the JTS jar file has to be placed in WEB-INF/lib instead of being placeable in more convenient places, like the 'lib' of the node or at a core level. Essentially, this is because spatial4j.jar is inside WEB-INF/lib which is loaded by a lower-level more internal classloader, and so it can only refer to things at its level or lower still.

If all the JTS using classes in Spatial4j were spun off into a separate jar, perhaps named spatial4j-jts-ctx.jar then that jar could go into a convenient lib dir as well as JTS, and it should work.

Another side benefit is that anyone fearing that Spatial4j is somehow tainted in that it refers to LGPL code (even though it's "optional") would be assuaged.

On the down side, especially for anyone without any classpath conundrums, this is yet another 'jar' file. I think it's worth it though.

[jdeolive]

+1 I like the idea of breaking out separate jars/modules for things that bring along additional dependencies not actually required by the core. I think that the support for jackson (#138) could also fall into this category as well (even though it's written with jackson as an optional dependency). It also sets the pattern for additional spatial libraries (like geo3d ?) to be added as well without bloating the core library. My $0.02

[dsmiley]

After #138 then I think I'll take a stab at this.

[dsmiley]

Ehh; I think I'll let it be after all since Solr will now be able to include JTS and as-such the pain point I felt here should vanish. That said if anyone wants to take this up then be my guest.