mgmt resources, optimize logic to load SDK version property

[XiaofeiCao]

Description

Goal

This PR isn't likely to fix the thread block, as it's still in reproduction.
What this PR is trying to do, is to at least lower the times needed to read from disk to an exponential degree.

Previously, for each AzureServiceClient instance, we need to read from disk once. If there be 100 clients, and 1000 AzureResourceManager instantiations, there would be 100 * 1000 = 100,000 disk reads.
Now it's at most 20+(number of the premium libraries).

Choices

The idea is to cache the result so that it would be available in next version request.
There are basically 3 timings to load the cache:

1. Class initialization phase. This is when each AzureServiceClient subclasses get loaded by classloaders.
2. Class instantiation phase. This is when each AzureServiceClient got instantiated through, e.g. new xx().
3. Method call phase. This is like lazy-loading and only load cache when it got a cache miss doing actual method calls.

Option 1 is most efficient, and most likely to solve the thread block, as there will be no concurrent issues, since classloader will always operation on single thread. Though the downside is that we probably need to modify codegen to add some kind of registration in all subclasses instantiation, e.g. through static block, which affects a lot.

Difference between option 2 and 3 is whether to pre-load caches during class instantiation.

This PR did option2, with assumption that concurrent method calls are more intensive than concurrent class instantiations, while also no need to touch all AzureServiceClient subclasses.

Result

Before this PR, concurrent initialization of 1000 AzureResourceManagers on 1000 threads takes roughly 8 seconds on my mac.
This PR reduces it to 2 seconds.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[XiaofeiCao]

New alternative approach: #47301