Record internal metric for SQL cache misses.

[breedx-splk]

In #2094 we introduced a cache for SQL sanitization/extraction to reduce the number of times that a familiar statement would need to undergo expensive parsing. This was done in order to help reduce the overhead of the very common jdbc instrumentation.

It is expected that most common applications and frameworks will have a fixed/finite set of SQL statements used at runtime. There will be dynamically generated SQL statements that happen for some users, but we expect these exceptions to be rare. Currently, when a SQL statement is not found in the cache and additional parsing has to happen, we log a message at trace, but this is likely to be unseen.

Let's create and increment an internal metric for parsed SQL cache misses. This will allow users and operators troubleshooting jdbc instrumentation to determine how effective the cache is. It could also allow tuning of this cache (size, lifetime, etc) for future users.

Before starting on this, we should agree what to call it and what its namespace should be.

[mateuszrzeszutek]

We could use SupportabilityMetrics for this