Ban use of unrelocated Guava classes

[shardulm94]

#1068 introduced a bundled-guava module which relocated Guava classes and changed existing imports to use these relocated classes. Unfortunately, new PRs can continue to use these classes resulting in ClassNotFoundErrors at runtime when using iceberg-spark-runtime.

e.g. java.lang.NoClassDefFoundError: org/apache/iceberg/shaded/com/google/common/base/Preconditions

This PR adds a checkstyle rule to ban use of unrelocated guava classes and also changes violating imports

[rdsr]

I'm +1 for this change

[massdosage]

Hmmm, the intention with the original PR is that the classpath would be set up in such a way that the other subprojects would not be able to see Guava on their classpath and these imports would give compile errors. @rdblue I guess you didn't manage to get that working? Perhaps #1067 will fix this? So this rule shouldn't be necessary and compile errors would give devs a warning earlier than checkstyle errors. I don't really mind having this as an extra safety net though.

[rdblue]

I'm looking into why Guava is in the classpath. I tested it with iceberg-api, but it looks like Guava is in the classpath in iceberg-core and other modules. It is a good idea to exclude it from the classpath where we can and also check that we don't reference it anywhere, since we don't ever want to leak it. I'll merge this.

Thanks @shardulm94!