Since there is no generic information in `flag_value.__init__()`,
`flag_value` descriptors get stored as `flag_value[<nothing>]` in mypy
strict mode and then the `__get__` overloads never match. This leads to
errors when using things like `permissions_instance.embed_links` since
`<nothing>` never matches `Permissions`.
The generic inheritance isn't needed at all since the type information
we care about comes from the call site of `__get__` and not the
instantiation of the descriptor.
This also adds asynchronous context manager support to allow for
idiomatic asyncio usage for the lower-level counterpart. At first
I wanted to remove Client.run but I figured that a lot of beginners
would have been confused or not enjoyed the verbosity of the newer
approach of using async-with.
If different persistent view instances are used within different
message_ids their callbacks will get called without differentiating
between them, leading to potential issues such as 404 errors. This
change makes it so N views with custom IDs bound to N message_ids
will no longer conflict with one another.
The first issue involved copied users which would lead to user updates
causing faster evictions of the cache than was expected.
The second issue involved users that weren't bound to an internal
lifetime eviction policy. These users would not get evicted.
For example, a user without mutual guilds or being part of the internal
cache in general (messages, DMs) would never end up being evicted for
some strange reason. To handle this case, store_user would get a
counterpart named create_user which would create a user without
potentially storing them in the cache. That way only users with a
bound lifetime within the library would be stored.