Add a clarification in the "Be careful about I/O in Providers" doc page with regards to iterating over original exception cause

Hi,

I was reading through some of the (quite good!) user guide and stumbled upon the [Be careful about I/O in Providers](https://github.com/google/guice/wiki/BeCarefulAboutIoInProviders) page. Therein, the first paragraph states:

> - Provider doesn't declare checked exceptions. If you're writing code that needs to recover from specific types of failures, you can't catch TransactionRolledbackException. ProvisionException allows you to recover from general provision failures, and you can [iterate its causes](http://google.github.io/guice/api-docs/latest/javadoc/com/google/inject/ProvisionException.html#getErrorMessages()), but you can't specify what those causes may be.

Unfortunately, I don't think this is quite right in all cases. The JVM is fully allowed to omit a stacktrace, provided a few criteria are met (method is hot, exception is implicit, exception has occurred prior and the JVM is aware of this). More details can be gleaned [here](https://stackoverflow.com/questions/58696093/when-does-jvm-start-to-omit-stack-traces).

I've tackled this issue before with some AOP code during which something like the following code:
```java
try {
joinPoint.proceed();
} catch (Throwable e) {
StackTraceElement[] ste = e.getStackTrace();
StackTraceElement first = ste[0];
log.error("...");
throw e;
}
```

threw an `ArrayIndexOutOfBoundsException`, as the JVM had omitted the Stacktrace for a method which had been generating a large amount of errors. It might be a bit out there, but I can imagine some scenario in which a request scoped instance leads to an error during provisioning, leading to numerous (potentially identical) exceptions being thrown, triggering this JVM behaviour.

Judging by the attention to detail I've seen in other spots of the user guide, this may be a useful addition on that page (provided I haven't missed anything).