Cache keys sometimes need to involve input that comes from another

source, such as a value in a database. While we're pretty careful about

how we compose these keys, there's always a risk of a cache key

poisoning vulnerability.
That sort of bug could manifest as a key structured like:

path:to:<value>[:optional_param]


Where value could potentially be my_value:forced_param.
To avoid these sort of issues, we'd need to escape the values going into

the key. The safest way of doing that consistently is leaving it up to a

central method to handle.
All of Djblets's caching methods now accept a cache key as a sequence of

strings. This includes cache_memoize, cache_memoize_iter, and

make_cache_key.
Each key in the sequence will be escaped, first converting any %

characters to %25 (escape code for %) and then any : characters to

%3A.
This is opt-in. Callers passing a plain string won't see any difference

in behavior. Those keys will be used as-is.
It does means that keys constructed as part of another key that's either

been normalized or contains escapable characters may get an unexpected

key in return.
Going forward, we'll want to make use of these sequences rather than

hard-coding strings, in order to ensure safety of all keys.

Unit tests pass.
Made use of this in some in-progress code.