Note: I've added a concurrency test for the NetTopologySuite plugin, which seems to show that it's fine to use the reader/writer streams concurrently. So I think our handlers are now fine.

Note that I'm still not 100% convinced it's a good idea to share type handlers. The reason for doing this is mainly multiplexing: we want to bind parameters to the type handler, and do parameter validation/length calculation before we push the command into the multiplexing channel (at that point there's no connector yet). We could simply re-bind the parameters in the multiplexing write loop, when actually writing the parameter data. This would incur a small perf hit, and it would still not allow sharing state between the validation and writing phases; but it would allow the handler to not be thread-safe (i.e. have state).

If we do need to have state in some handler some day (imagine if NetTopologySuite's streams weren't thread-safe), we'd either have to hack some way to store state on the connector, or re-instantiate that state for every value, which could be expensive.

But given that all handlers currently look fine, I guess it's OK to just go in this direction for now, rather than compromising perf and doing something complex for some theoretical future problem. Let me know what you guys think.

/cc @NinoFloris @vonzshik @Brar