ticket-32076

• Based on DEP 0009 and the implementation found here
• Copied all doc strings from the synchronous methods
• Adds async cache methods to BaseCache and DummyCache.

Issues I currently see are:

1. The request finished signal being unable to properly close all cache connections (more details in original ticket). This can be found in django.core.cache (init file).
2. This has been implemented as per DEP 0009 Lots of times in several areas in Django, the cache is called by doing if "string" in cache. The async method cannot handle the magic method __contains__ unless you use sync_to_async. I dislike context switching, so I would rather not touch that, but I can see why people would want to "accidentally" use it, even if in the documentation we mention it will not be performant and people should strive to use await cache.has_key("string") instead.
3. Current session backend is not handling the async methods. @felixxm Made a good point about being a partial solution and why BaseCache may not be good enough for this implementation; I'm currently writing a session backend for my websocket implementation found here (I'll be moving the code to a separate repository soon to demonstrate the functionality). The issue I immediately ran into was logging in since I wanted to see how I can validate the session for that custom websocket script. If we went with what @felixxm said, then the async methods in BaseCache would look like:

async def get_async(value):
    return sync_to_async(self.get(value))

The issue I see with that is if a library accidentally doesn't implement the get_async() method, then the error will say that the get method is not created when it should really say the dev needs to create the get_async method.
4. I'm not going to have time to write documentation (Edit rephrased: I'm terrible at documentation and heavily discouraged).
5. I've added LocMem to this PR. The only change is that we're adding asyncio.Lock for async context. I think I can rework this to take advantage of the RunTimeError so we know which context we're in. That means we don't need to create two different locks. If you'd like, I can add my setup for LocMem backend. I'm not too sure about the tests though. As I was copying and pasting all those test cases, my computer started burning up...