The [blocking `RM_Call`](redis/redis#11568) was introduce on Redis 7.2. The idea is to give a module writter the ability to perform blocking commands like `BLPOP` using `RM_Call`. This PR adds this functionallity to `redismodule-rs`.

In order to be able to invoke blocking commands, the user need to use `call_blocking` instead of `call` or `call_ext`. `call_blocking` will return an enum that can either be a regular reply (like `call_ext` returns) or it can be a `FutureCallReply`.

The `FutureCallReply` can be used to set `on_done_handler` that will be called when the command gets unblock. The `on_done_handler` gets the command reply as an intput. The `FutureCallReply` not outlive the `Context` that was used to invoke the  blocking command. This is because the `on_done_handler` must be set before the Redis GIL is released. This restriction forces it.

After setting the unblock handler, the user will get a `FutureHandler` object that can be use to abort the command invocation. The abort is done base on a best effort approach. And important details is that the `FutureHandler` must be freed when Redis GIL is held, this is why we introduce a `dispose` function (that gets a lock indicator) and not counting on `Drop` implementation.

A simple usage example:

```rust
fn call_blocking(ctx: &Context, _: Vec<RedisString>) -> RedisResult {
    // create blocking call options
    let call_options = CallOptionsBuilder::new().build_blocking();

    // call the blocking command
    let res = ctx.call_blocking("blpop", &call_options, &["list", "1"]);

    // check the reply, if its a future, block the client until the
    // future is resolved.
    match res {
        PromiseCallReply::Resolved(r) => r.map_or_else(|e| Err(e.into()), |v| Ok((&v).into())),
        PromiseCallReply::Future(f) => {
            let blocked_client = ctx.block_client();
            f.set_unblock_handler(move |_ctx, reply| {
                let thread_ctx = ThreadSafeContext::with_blocked_client(blocked_client);
                thread_ctx.reply(reply.map_or_else(|e| Err(e.into()), |v| Ok((&v).into())));
            });
            Ok(RedisValue::NoReply)
        }
    }
}
```

**Notice** a nice possible improvement would be to integrate this feature with rust async await. We leave this for future PR.

The [blocking `RM_Call`](redis/redis#11568) was introduce on Redis 7.2. The idea is to give a module writer the ability to perform blocking commands like `BLPOP` using `RM_Call`. This PR adds this functionality to `redismodule-rs`.

In order to be able to invoke blocking commands, the user need to use `call_blocking` instead of `call` or `call_ext`. `call_blocking` will return an enum that can either be a regular reply (like `call_ext` returns) or it can be a `FutureCallReply`.

The `FutureCallReply` can be used to set `on_done_handler` that will be called when the command gets unblock. The `on_done_handler` gets the command reply as an input. The `FutureCallReply` not outlive the `Context` that was used to invoke the  blocking command. This is because the `on_done_handler` must be set before the Redis GIL is released. This restriction forces it.

After setting the unblock handler, the user will get a `FutureHandler` object that can be use to abort the command invocation. The abort is done base on a best effort approach. And important details is that the `FutureHandler` must be freed when Redis GIL is held, this is why we introduce a `dispose` function (that gets a lock indicator) and not counting on `Drop` implementation.

A simple usage example:

```rust
fn call_blocking(ctx: &Context, _: Vec<RedisString>) -> RedisResult {
    // create blocking call options
    let call_options = CallOptionsBuilder::new().build_blocking();

    // call the blocking command
    let res = ctx.call_blocking("blpop", &call_options, &["list", "1"]);

    // check the reply, if its a future, block the client until the
    // future is resolved.
    match res {
        PromiseCallReply::Resolved(r) => r.map_or_else(|e| Err(e.into()), |v| Ok((&v).into())),
        PromiseCallReply::Future(f) => {
            let blocked_client = ctx.block_client();
            f.set_unblock_handler(move |_ctx, reply| {
                let thread_ctx = ThreadSafeContext::with_blocked_client(blocked_client);
                thread_ctx.reply(reply.map_or_else(|e| Err(e.into()), |v| Ok((&v).into())));
            });
            Ok(RedisValue::NoReply)
        }
    }
}
```

**Notice** a nice possible improvement would be to integrate this feature with rust async await. We leave this for future PR.

**Notice** The PR also updates the `redismodule.h` file.

blocking RM_Call was introduced on: #11568, It allows a module to perform
blocking commands and get the reply asynchronously.If the command gets
block, a special promise CallReply is returned that allow to set the unblock
handler. The unblock handler will be called when the command invocation
finish and it gets, as input, the command real reply.

The issue was that the real CallReply was created using a stack allocated
RedisModuleCtx which is no longer available after the unblock handler finishes.
So if the module keeps the CallReply after the unblock handler finished, the
CallReply holds a pointer to invalid memory and will try to access it when the
CallReply will be released.

The solution is to create the CallReply with a NULL context to make it totally
detached and can be freed freely when the module wants.

Test was added to cover this case, running the test with valgrind before the
fix shows the use after free error. With the fix, there are no valgrind errors.

unrelated: adding a missing `$rd close` in many tests in that file.

In #11568 we removed the NOSCRIPT flag from commands and keep the BLOCKING flag.
Aiming to allow them in scripts and let them implicitly behave in the non-blocking way.

In that sense, the old behavior was to allow LPOP and reject BLPOP, and the new behavior,
is to allow BLPOP too, and fail it only in case it ends up blocking.
So likewise, so far we allowed XREAD and rejected XREAD BLOCK, and we will now allow
that too, and only reject it if it ends up blocking.

In #11568 we removed the NOSCRIPT flag from commands, e.g. removing
NOSCRIPT flag from WAIT. Aiming to allow them in scripts and let them
implicitly behave in the non-blocking way.

This PR remove NOSCRIPT flag from WAITAOF just like WAIT (to be
symmetrical)).
And this PR also add BLOCKING flag for WAIT and WAITAOF.

In redis#11568 we removed the NOSCRIPT flag from commands, e.g. removing
NOSCRIPT flag from WAIT. Aiming to allow them in scripts and let them
implicitly behave in the non-blocking way.

This PR remove NOSCRIPT flag from WAITAOF just like WAIT (to be
symmetrical)).
And this PR also add BLOCKING flag for WAIT and WAITAOF.

In redis#11568 we removed the NOSCRIPT flag from commands, e.g. removing
NOSCRIPT flag from WAIT. Aiming to allow them in scripts and let them
implicitly behave in the non-blocking way.

This PR remove NOSCRIPT flag from WAITAOF just like WAIT (to be
symmetrical)).
And this PR also add BLOCKING flag for WAIT and WAITAOF.