[HZ-5434] FencedLock for Asyncio

[yuce]

Ported FencedLock proxy to asyncio.

The asyncore variant uses actual thread IDs to disable re-entrancy.
That's not useful with the asyncio variant, so currently the thread ID 0 is used when necessary.
I've omitted docs that refer to threads, and tests that use threads.
I'll push another PR to add those after lock context implementation.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 82.18391% with 31 lines in your changes missing coverage. Please review.
✅ Project coverage is 94.14%. Comparing base (ec03ad8) to head (077a800).

Files with missing lines	Patch %	Lines
hazelcast/internal/asyncio_proxy/fenced_lock.py	80.64%	30 Missing ⚠️
hazelcast/internal/asyncio_proxy/cp_manager.py	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #818      +/-   ##
==========================================
- Coverage   94.22%   94.14%   -0.09%     
==========================================
  Files         411      412       +1     
  Lines       27427    27601     +174     
==========================================
+ Hits        25844    25984     +140     
- Misses       1583     1617      +34     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[emreyigit]

How are you going to protect lock ownership without thread id? There will be concurrent runs, right?

[yuce]

How are you going to protect lock ownership without thread id? There will be concurrent runs, right?

The lock is reentrant for lock attempts with the same client, similar to the Node.js client, so data races will happen with operations that uses the same client.
I'll push another PR that uses a pseudo-task ID to be used instead of the thread ID, which will enable us to distinguish between tasks.