feature:[loom] replace the usages of synchronized with ReentrantLock at saga module

[lightClouds917]

• I have registered the PR changes.

Ⅰ. Describe what this PR did

replace the usages of synchronized with ReentrantLock at sage module

To use virtual threads in JDK 21, we need to remove the usage of synchronized to prevent the issue where "a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier."

There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier:

When it executes code inside a synchronized block or method, or When it executes a native method or a foreign function.
Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers.

The scheduler does not compensate for pinning by expanding its parallelism. Instead, 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 instead. There is no need to replace synchronized blocks and methods that are used infrequently (e.g., only performed at startup) or that guard in-memory operations. As always, strive to keep locking policies simple and clear.

You can refer to the following documents:

https://openjdk.org/jeps/444
https://openjdk.org/projects/loom/

Ⅱ. Does this pull request fix one issue?

fixed #7173

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 52.18%. Comparing base (a1aba35) to head (6c34225).
Report is 1 commits behind head on 2.x.

Files with missing lines	Patch %	Lines
...io/seata/saga/proctrl/impl/ProcessContextImpl.java	50.00%	1 Missing ⚠️
...he/seata/saga/proctrl/impl/ProcessContextImpl.java	50.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7174      +/-   ##
============================================
+ Coverage     52.16%   52.18%   +0.01%     
- Complexity     6814     6817       +3     
============================================
  Files          1154     1154              
  Lines         41116    41122       +6     
  Branches       4820     4820              
============================================
+ Hits          21450    21459       +9     
+ Misses        17628    17623       -5     
- Partials       2038     2040       +2     

Files with missing lines	Coverage Δ
...ata/saga/proctrl/eventing/impl/DirectEventBus.java	81.48% <100.00%> (ø)
.../engine/invoker/impl/SpringBeanServiceInvoker.java	56.88% <100.00%> (ø)
...ga/statelang/domain/impl/ServiceTaskStateImpl.java	76.92% <100.00%> (+1.92%)	⬆️
...io/seata/saga/proctrl/impl/ProcessContextImpl.java	14.28% <50.00%> (+2.16%)	⬆️
...he/seata/saga/proctrl/impl/ProcessContextImpl.java	80.39% <50.00%> (-1.25%)	⬇️

... and 5 files with indirect coverage changes

[slievrly]

The getLock method doesn't really fit a universal business process or template setup, so it's not quite suitable to include it in the interface.