scope_lock behaves differently if the mutex gets unlocked manually

The following example behaves very different if the mutex gets unlocked manually.
I think it behaves correctly if the destructor is called when the lock gets out of scope.
But if `unlock` is called manually then multiple coroutines enter the critical section.

```cpp
#include "asio/executor.hpp"
#include "asio/this_coro.hpp"
#include
#include
#include
#include
#include
#include
#include
#include
#include

using namespace asio::experimental::awaitable_operators;
using namespace std::chrono_literals;

avast::asio::async_mutex mtx;
int global = 0;

auto inc() -> asio::awaitable
{
for(int i = 0; i < 100; i++) {
// lock
auto lock = co_await mtx.async_scoped_lock(asio::use_awaitable);

// print
fmt::print("{}\n", global);

// yield coroutine such that another coroutine could be executed
asio::steady_timer timer(co_await asio::this_coro::executor);
timer.expires_after(0s);
co_await timer.async_wait(asio::use_awaitable);

// increment global
global++;

//if the following line is uncommented the lock does not seem to work anymore
// mtx.unlock();
}
}

auto main() -> int
{
asio::io_context context(16);

for(int i = 0; i < 1000000; i++) {
asio::co_spawn(context,
inc(),
asio::detached);
}

context.run();
}

```

Start at the async_scoped_lock and unlock implementation exercised by the reproducer, then run the provided coroutine example with and without the manual unlock. Trace the mutex state across scoped destruction and explicit unlocking. Done means multiple coroutines no longer enter the critical section simultaneously, with behavior covered by a regression test.

Written by the indexing model from the issue text.