the `PolarisMetaStoreManager` interface methods all take a `PolarisCallContext` parameter
because they need access to `PolarisCallContext.getMetaStore` aka the persistence session.
also occasionally the `RealmContext` and `RealmConfig` is needed.

this means `PolarisMetaStoreManager` is only usable within a request-scope.
`MetaStoreManagerFactory.getOrCreateMetaStoreManager` impls suggests that there needs to
be one shared `PolarisMetaStoreManager` instance per realm.
however if we look at the `PolarisMetaStoreManager` impls (`AtomicOperationMetaStoreManager`
and `TransactionalMetaStoreManagerImpl`) we can see that they dont have any state themselves,
the fields only reference application-scoped collaborators.

those 2 observations combined mean that in order to reduce the dependency on
`PolarisCallContext` the `PolarisMetaStoreManager` has to become request-scoped.
note that if custom implementations would need any state sharing for a realm, they are still
free to do so in their custom `MetaStoreManagerFactory` implementations, as they can
initialize the request-scoped `PolarisMetaStoreManager` with whatever data they need.

when `PolarisMetaStoreManager` is request-scoped the `getOrCreateSession` method also becomes
a private implementation detail of the `MetaStoreManagerFactory`.
the `EntityCache` / `InMemoryEntityCache` however can no longer operate on a single
`PolarisMetaStoreManager` and the one from the request needs to be passed as a parameter in
all the methods now.