Address various JDBC instrumentation issues

[richardstartin]

This PR makes a few changes to the JDBC instrumentation

1. Caches connection URL parsing since some applications connect frequently, the parsing is quite slow, and connecting often takes a driver level lock. This should fix an issue for Apache Phoenix users where connection creation is more common than in applications using traditional connection pools.
2. Separates out and namespaces DB2 Connection and PreparedStatement instrumentations, which have expensive type matchers. This means that unless DB2 is being used, JDBC matching is about as cheap as it can get.
3. Add Redshift's CallableStatement implementation, which was missed in Add support for redshift JDBC #2511

[richardstartin]

Adding this allows to muzzle the instrumentation now that DB2 is matched separately from the rest for startup performance reasons.

[bantonsson]

👍

[bantonsson]

Yeah, it's not relevant to this PR, but why is there an extra { indentation here?

[richardstartin]

I think it's actually possible to do this another way without needing to trust unwrapping or to know anything but the connection names, which would simplify both statement and prepared statement instrumentations, which would just be to inject the DBInfo into the statements when they are created, and if we can't find DBInfo, we don't span the execute call, because it means the statement was not created by one of the connection types we target.

[richardstartin]

@bantonsson I have dropped the statement instrumentation changes and the recursive connection unwrapping because I want to solve this problem a different way later.