BundledTypeRegistry's use of shaded Guava problematic when used outside Oak

The oak-shaded-guava bundle exports shaded guava packages with a version that is defined by google to match the version of the upstream artifact. While it is a semantic versioning scheme, it follows the API contract of the entire artifact, and does not distinguish API changes in included packages like .base and .collect at a granular level, which can result in otherwise avoidable OSGi wiring errors when references to guava types leak outside of the greater Oak API boundary, such as when classes are embedded or when guava types are explicitly referenced in signatures outside of oak-shaded-guava.

oak-commons should endeavor to provide a stable facade API for the simpler parts of the guava library that are referenced at runtime by other oak bundles, such as newHashMap(), ImmutableList.copyOf(), Preconditions.check*, and perhaps Closer. 

One example I know of that could where I could benefit from this approach almost immediately is a project where I am embedding BundlingConfigInitializer and BundledTypesRegistry from oak-store-document in a customized repository configuration. When BundledTypesRegistry is embedded, it brings with it imports of ImmutableMap, Maps, and Sets from org.apache.jackrabbit.guava.common.collect. With the recent guava upgrade to 33.0.0 in OAK-10605 in 1.61-SNAPSHOT, the custom repository bundle fails to activate because the previous import-package bounds no longer match: org.apache.jackrabbit.guava.common.collect;version=[32.1.3,33).