Summary:
**Issue 1 :**
Previously, `lock_timeout` was not functional for any lock request

**Fix:**
This change enables `lock_timeout` for advisory locks. Here is how to use it:
```
SET lock_timeout = '2s';
```
When acquiring an advisory lock, the RPC timeout is determined by the minimum of: `lock_timeout, statement_timeout, FLAGS_ysql_client_read_write_timeout_ms`
If `lock_timeout` is set to 0, it means no explicit timeout is applied, and the system falls back to `statement_timeout` or the `FLAGS_ysql_client_read_write_timeout_ms`.

**Issue 2:**
In PostgreSQL, `lock_timeout` and `statement_timeout` is enforced precisely. However, currently in YugabyteDB, **actual timeout = lock_timeout or statement_timeout + 10-30 seconds**.
This happens because advisory lock requests in WaitQueue` only honor `refresh_waiter_timeout_ms` (default 30000ms), and do not consider the RPC deadline.
The detailed flow is as follows:
1. The TServer receives a WRITE_OP advisory lock request. If the lock is currently held by another operation, the request is added to the WaitQueue.
2. In WaitQueue, we constantly check whether we are waiting for more than ` refresh_waiter_timeout_ms`, and if we are still in the waiting state, then returns a `TimeoutError`.
3. If the RPC deadline hasn't yet expired, the client retries the WRITE_OP, which goes back to step 1.
As you can see, the RPC deadline is only checked at step 3. However, the RPC deadline should also be checked periodically in step 2 — while the request is still waiting in the WaitQueue.

**Fix:**
In each polling cycle within WaitQueue, also check the RPC deadline and expire the waiter if the deadline has been exceeded.

Jira: DB-15880

Test Plan: ./yb_build.sh --cxx-test pgwrapper_pg_advisory_lock-test --gtest_filter PgAdvisoryLockTest.VerifyLockTimeout

Reviewers: bkolagani, myang, #db-approvers

Reviewed By: bkolagani, myang, #db-approvers

Subscribers: rthallam, ybase, yql

Differential Revision: https://phorge.dev.yugabyte.com/D42965