In Django, when you set a cache backend, you're stuck with it. Changing

backends after-the-fact doesn't really work without restarting the

application. This is because the 'cache' variable that gets imported is

an instance of the backend computed when django.core.cache loaded.
While we didn't used to have any issues from this in Review Board, some

new imports resulted in the cache backend being computed before we could

set the proper settings.CACHES entries.
This change gives us some flexibility by introducing

ForwardingCacheBackend. Projects can set this as the default cache and

then specify the real desired cache backend as another named backend,

and point ForwardingCacheBackend to it. All requests and operations will

go through there.
The siteconfig support has been updated to work with this. Nothing

really changes for consumers. Projects not suffering from the early

import problem will get the correct settings automatically, and projects

that do suffer from it will just need to make a change in settings

anyway (since prior to this, that was the only reliable way to set cache

in that situation).
While here, I also fixed up the normalization of the class name to not

use deprecated modules.

Wrote a script that would load the current cache, show the backend,

set a new one in siteconfig, apply siteconfig settings, and show the new

backend.
Without this new backend, the desired backend wouldn't be set.
With this backend, the desired backend was set, and I could verify that

it was being used for all caching operations.