Migrating commands to a mixin

[chayim]

This patterns allows for the reuse of these commands across connection types, including modules that are based on this client.

This doesn't break any APIs as evident by the lack of change in unit tests.

Pull Request check-list

Please make sure to review and check all of these items:

• Does $ tox pass with this change (including linting)?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

NOTE: these things are not required to open a PR and can be done
afterwards / while the PR is open.

Description of change

Commands, and their associated helpers were moved from redis/client.py and added to redis/commands.py.

[barshaul]

Can the 'commands' class include only base redis commands, by separating sentinel and cluster commands into their own command classes?
Then we can use multiple inheritance for special Redis clients and to ensure its API only includes its relevant commands

[chayim]

@barhsaul Great idea - I did that, after the 6.2.5 base docker upgrade. It still feels missing somehow given the parse_sentinel* helpers. Those might move as well 🤷

[chayim]

It looks like there are some great sentinel commands in #834 that we can also reference here. Once this is merged, I'd look at merging that in.

[abrookins]

This looks good to me and should help compose clients that add additional commands. 👍

One day I'd like to figure out how to define the logic for core commands in one place that we can use for both redis-py and aioredis-py, but that's for another day.