[release/9.4] Made changes to how parameter.Value works

[github-actions]

Backport of #10354 to release/9.4

/cc @davidfowl

Description

This change was motivated by issues found while testing async parameter resolution. Previously, ParameterResource.Value was used in many places without properly waiting for values to resolve, causing failures. Now, ParameterResource.Value calls ParameterResource.GetValueAsync(...).GetAwaiter().GetResult(), which—while not ideal—ensures that both sync and async access behave consistently and avoid inconsistent state.

There is some risk of introducing deadlocks for consumers that previously used .Value, but if .Value is accessed before the TCS is set, it will throw as before.

• Value now blocks (sync over async) waiting for value resolution if WaitForValueTcs is set.
• Made GetValueAsync on ParameterResource public.
• Updated most code outside of tests to use GetValueAsync instead of Value.

Fixes #10352

Customer Impact

• Fixes scenarios where parameter values were not resolved synchronously, preventing initialization failures due to unresolved parameters.

Testing

• Added/updated unit tests to verify correct blocking/waiting and error scenarios.
• Validated in scenarios requiring async parameter resolution.

Risk

• Potential deadlocks for consumers using .Value in a deadlock-prone context; mitigated by existing exception handling.

Regression?

• No. This change aligns sync and async access and prevents failures previously possible.