Avoid `synchronized` during blocking operations (loom friendliness)

Virtual threads, introduced in [JEP 444](https://openjdk.org/jeps/444), are forced to pin to their carrier threads when in a `synchronized` block. Since `AmazonDynamoDBLockClient` [synchronizes on `LockItems`](https://github.com/awslabs/amazon-dynamodb-lock-client/blob/0cd3fe8a3d3c3876aef088d6c336a6f074816b2b/src/main/java/com/amazonaws/services/dynamodbv2/AmazonDynamoDBLockClient.java#L836) while performing blocking dynamodb operations, using the lock client from a virtual thread pins the virtual thread to the carrier thread while waiting for the operation to complete (which sort of defeats the purpose of virtual threads).

JEP 444 suggests replacing `synchronzied` blocks that contain long blocking I/O operations with `ReentrantLock`

> avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use [java.util.concurrent.locks.ReentrantLock](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html) instead.

I'd be happy to open a PR if you're amenable to tossing a `ReentrantLock` in `LockItem` to replace the `synchronized` blocks

Start in src/main/java/com/amazonaws/services/dynamodbv2/AmazonDynamoDBLockClient.java, especially the synchronized LockItems section around line 836, and inspect the LockItem synchronization used around blocking DynamoDB operations. Compare the relevant locking paths with JEP 444's ReentrantLock guidance. Done means those blocking paths no longer use synchronized locking and the existing test suite still passes.

Written by the indexing model from the issue text.