Change JMeter properties backend to a lock-free representation to avoid run-time lock contention

### Use case

### Description
In high-concurrency performance testing scenarios, global property queries performed during active test execution (for example, through JSR223 Groovy scripts accessing the implicit `props` object or through `${__P()}` / `${__property()}` functions) create a global synchronization bottleneck.

`java.util.Properties` inherits directly from `java.util.Hashtable`, where core accessors like `.get(Object)` and mutators like `.put()` are declared as `synchronized` methods. In highly concurrent test plans (e.g. 500+ threads executing JSR223 elements concurrently), threads end up serialization-blocked waiting to acquire the monitor lock of the global properties instance.

### Possible solution

Introduce a subclass of `java.util.Properties` named `ConcurrentProperties` which internally delegates read queries to a backing `ConcurrentHashMap`, while keeping writes synchronized and in sync with the parent `Hashtable` data model. This provides completely lock-free read lookups under concurrent scripts while maintaining full type compatibility (`instanceof java.util.Properties`).

### Possible workarounds

_No response_

### JMeter Version

6.0.0-SNAPSHOT

### Java Version

_No response_

### OS Version

_No response_

Start by tracing the JMeter properties backend used by JSR223 Groovy scripts and the `${__P()}`/`${__property()}` functions. Define how concurrent reads through the implicit `props` object can avoid global lock contention while writes remain synchronized and compatible with `java.util.Properties`; done means preserving the existing type behavior under concurrent access.

Written by the indexing model from the issue text.