refactor:(loom) change synchronized methods on TypeInfoCache to use Lock

[rbygrave]

Referencing #1951 for outline / motivation which is to improve compatibility with loom.

Change TypeInfoCache replacing the synchronized methods with use of ReentrantLock.

The diff for this PR is best viewed ignoring whitespace due to indentation change

Changes to Existing Features:

• Does this break existing behaviour? If so please explain.
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

[bokken]

@vlsi, @davecramer the expectation is that each Connection has it's own unique TypeInfoCache instance, correct? So our synchronization concern is not /concurrent/ access to individual methods which mutate local state, but rather visibility of those mutations in a future "transaction" when the Connection is re-used on a different thread?
If that is the case, it seems better to change to ConcurrentHashMap and remove all explicit synchronization. That would not only simplify this class, it potentially improves performance. It would certainly seem to provide more /consistent/ performance irrespective of biased locking potentially being removed.
Even in the face of concurrent use (which we would not expect), the risk appears to be limited to repeated work to query from the database and populating values into the maps. There does not appear to be risk of inconsistent state causing issues for either concurrent user (which again, almost certainly has other problems).

[davecramer]

@brettwooldridge I think there was some concern over people sharing connections. That said there is no guarantee that JDBC is threadsafe however some expect it to be. I like the idea of using a concurrent map though
+1

[rbygrave]

Closing this PR - it was replaced by #2635