Using the is_key_ready() callback plus the reply callback later, creates
different issues AFAIK:

1. More complex API.
2. We need to call the reply callback() ASAP if the is_key_ready()
interface returned success, however the internals do not work in that
way, so when the reply callback is called the setup could be different.
To fix that, there is to break the current design that handles the
unblocked clients asyncrhonously, and run the list ASAP.

Now we handle propagation when we free the context.

Make module tests pass with valgrind, and fix a leak in diskless load

Modules: improve tests Makefile.

Module API for LatencyAddSample

Fix some minor typos in comments

fix comment typo in redis-cli.c

Typo fix: kill -> still

Introduce ReplyWithVerbatimString, ReplyWithEmptyArray, ReplyWithNull…

Modules: make unloading module more safe

Introduce ReplyWithVerbatimString, ReplyWithEmptyArray, ReplyWithNullArray and ReplyWithEmptyString to redis module API

As we know if a module exports module-side data types,
unload it is not allowed. This rule is the same with
blocked clients in module, because we use background
threads to implement module blocked clients, and it's
not safe to unload a module if there are background
threads running. So it's necessary to check if any
blocked clients running in this module when unload it.

Moreover, after that we can ensure that if no modules,
then no module blocked clients even module unloaded.
So, we can call moduleHandleBlockedClients only when
we have installed modules.

Removes some boilerplate per module, add clean target.

We can't use the same client at the same time when re-entering the hook.

Calling a module hook callback may result in callback operations in turn
triggering other events the module is subscribed too. We don't want to
trigger those, it's unsafe and quite confusing, and to do it correcly we
would need to maintain an event list: quite a more complex
implementation.