Avoid classloading LatencyUtils when not configured

[shakuzen]

The default MeterRegistry configuration uses a NoPauseDetector, which does not need to use any LatencyUtils classes. This change avoids classloading LatencyUtils classes, which makes it possible for end users to exclude the LatencyUtils dependency and not have any issues at runtime.

Without this change, when excluding the LatencyUtils dependency from your application classpath, the following exception is thrown when registering a Timer.

java.lang.NoClassDefFoundError: org/LatencyUtils/PauseDetector
	at io.micrometer.core.instrument.AbstractTimer.initPauseDetector(AbstractTimer.java:104) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.AbstractTimer.<init>(AbstractTimer.java:84) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.prometheus.PrometheusTimer.<init>(PrometheusTimer.java:57) ~[micrometer-registry-prometheus-1.9.1.jar:1.9.1]
	at io.micrometer.prometheus.PrometheusMeterRegistry.newTimer(PrometheusMeterRegistry.java:320) ~[micrometer-registry-prometheus-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.MeterRegistry.lambda$timer$2(MeterRegistry.java:318) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.MeterRegistry.getOrCreateMeter(MeterRegistry.java:618) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.MeterRegistry.registerMeterIfNecessary(MeterRegistry.java:570) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.MeterRegistry.timer(MeterRegistry.java:316) ~[micrometer-core-1.9.1.jar:1.9.1]
	at io.micrometer.core.instrument.Timer$Builder.register(Timer.java:399) ~[micrometer-core-1.9.1.jar:1.9.1]
	at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.getTimer(WebMvcMetricsFilter.java:161) ~[spring-boot-actuator-2.7.1.jar:2.7.1]

Closes #1599

[shakuzen]

I would like to directly test that a user can exclude e.g. LatencyUtils from their classpath and not have issues as long as they are not configuring a PauseDetector. However, I could not find an easy way to run one test with a different classpath. Spring Boot has the ModifiedClassPathExtension to achieve what we want. We may want to consider copying that. It does seem to have some reflection depending on JUnit internals, which is not ideal, but it's also not ideal to not directly test behavior we intend to provide to users.