Make prepared geometry (more?) thread-safe

[dbaston]

This PR makes prepared geometries thread-safe, or at least more thread safe than they used to be. The clang thread sanitizer reports no errors on the included test. valgrind --tool=helgrind reports many, but I'm wondering it isn't correctly understanding the std::call_once construct.

This introduces a few number of inconsistencies with JTS. I think they are pretty minor.

• MonotoneChain::getEnvelope no longer takes an expansionDistance argument. That distance is now provided to MonotoneChainBuilder, and the envelopes are eagerly constructed. The previous handling of this parameter was arguably incorrect, in any case.
• MCIndexSegmentSetMutualIntersector::process can now accept a SegmentIntersector argument so that multiple threads can call process with their own SegmentIntersector. I did not change the entire SegmentSetMutualIntersector interface, just this one class.
• FastSegmentSetIntersector no longer shares a LineIntersector between calls.
• IndexedPointInAreaLocator eagerly builds its index. This should be OK since the locator itself is (usually?) lazily-constructed.

I haven't yet done performance testing to see if there is a penalty for single-threaded uses.

[robe2]

@dbaston This says it's slated for 3.13, is that still true, or should we push to 3.14. I've pushed to 3.14, push back if I am mistaken.

[gauteh]

Hi, I believe we are seeing this in roaring-landmask (https://github.com/gauteh/roaring-landmask/issues/25) through the rust-bindings (https://github.com/georust/geos/issues/95).