Improve Search performance by introducing per-tag index hashes

[Difegue]

I don't think search can get faster than it currently is if we keep looking at every file each time.
The most simple solution imo is to build index tables for each namespace: The structure for this already exists in the stats minion job, it's mostly a matter of extending it so that Search can rely on those stat tables as well.

In case the stat tables aren't built (first searches), we'll probably have to fallback on the existing look-in-every-redis-key algorithm.

[Difegue]

Some notes on the search rewrite that's currently landing (wow, it's been more than a year...):

• Spaces are no longer a delimiter for different tags in a search prompt, commas should now be used instead. This matches what the autocompletion box does and how metadata as a whole is entered into the app, so I don't think this will cause too much pain.
• Tags will for now only be accepted as exact matches without any wildcards, aka category:doujinshi (or doujinshi if no namespaces). Spaces before/after a tag will be accepted. You might have to rewrite some of your dynamic categories.
• Title searches will work the same as before (quotes or $ for an exact match, ? * _ % as wildcards

The new system makes heavy use of Redis sets and sorted sets, which are all lodged in a separate, third database.
See the DB Architecture document. (the config keys moving to a fourth database is a pending change.)

[Difegue]

Additional comment: Search now requires the index tables to be built (does so on app start, and then updates them as tags/titles/etc are modified), so large instances might take a few mins to get a usable search again after updating.

I haven't added a visual warning for this, but it'd certainly be a possibility.