Leave a single CachePopulator and choose sync/async mode automatically

In this issue, I list several ideas regarding refactoring/improvement of `CachePopulator` subsystem.

1. It seems to me that `BackgroundCachePopulator` and `ForegroundCachePopulator` would be much more intuitively called Sync/Async ("background cache population" and "foreground cache population" terms in docs should then be updated to "synchronous/asynchronous cache population").

2. There could be a single implementation. The executor may be `DirectExecutorService` in the "sync" case.

3. It seems to me that the crucial difference between sync and async is whether blocking cache (Redis/Memcached) or local, (mostly) non-blocking cache (Caffeine) is used. At least, this should be highlighted in docs; at most, the mode of cachePopulator should be chosen automatically depending on the configured type of the cache.

4. Does it make any sense to make async cache populator which pushes results to remote cache to have more than 1 thread? After all, we will be hitting the same bottleneck - the local NIC. So async populator may just have a queue and a single thread takes cache entries from the queue and tries to push them to remote cache.

Start by tracing the CachePopulator subsystem and comparing BackgroundCachePopulator, ForegroundCachePopulator, and DirectExecutorService. Review how Redis/Memcached and Caffeine are configured, along with the documentation terminology; the issue needs a concrete design decision and acceptance criteria before implementation can be considered done.

Written by the indexing model from the issue text.