Fix TopicHistoryStorage, which is used when no cache applies
We fall back to database (instead of cache) in 2 cases:
- index applies but some data is missing, in which case it's fetched by backingStoreFindMulti
- no index applies (e.g. out of range - only first x entries are cached) in which case it's fetched from storage::findMulti
Which means that findMulti can be called directly, with the exact
same $queries we send to cache indices (TopicHistoryIndex)
TopicHistoryIndex was doing some manipulations: it would expect a bogus
primary key "topic_root_id" and figure out the real queries from there.
However, the storage counterpart was never properly addressed.
I've moved the resolution code to TopicHistoryStorage, which can now
also deal with "topic_root_id". The original code in TopicHistoryIndex
has been replaced with a simple call to the code that's now been moved.