feat(testing): support envconfig in integration test harness

[THardy98]

What was changed

Add opt-in envconfig support to .NET integration-test harness.

Why?

This enables integration tests to target arbitrary Temporal server environments, including local, staging, release, and Temporal Cloud environments.

Checklist

1. Part of Run integration tests against cloud features#851

2. How was this tested:

• An integration test runs a Workflow against an envconfig-selected server using the standard shared test harness and a non-default namespace.

3. Any docs updates needed?
   No

[jmaeagle99]

It looks a little strange to have to (1) set envConfigOptions in the ctor, (2) set an environment variable, and then (3) call InitializeAsync, which then decides whether the envConfigOptions is used based on the environment variable.

How about we have the default constructor pass an empty ProfileLoadOptions if the environment variable is set and simplify the check in InitializeAsync?

public WorkflowEnvironment()
    : this(UseEnvConfigFromEnvironment() ? new ClientEnvConfig.ProfileLoadOptions() : null)
{
}

internal WorkflowEnvironment(ClientEnvConfig.ProfileLoadOptions? envConfigOptions)
{
    this.envConfigOptions = envConfigOptions;
    this.kitchenSinkWorker = new(StartKitchenSinkWorker);
}

public async Task InitializeAsync()
{
    if (null != envConfigOptions)
    {
        var options = ClientEnvConfig.LoadClientConnectOptions(envConfigOptions);
        env = new(await TemporalClient.ConnectAsync(options));
    }
    else if (Environment.GetEnvironmentVariable("TEMPORAL_TEST_CLIENT_TARGET_HOST") is string host)
    ...
}

private static bool UseEnvConfigFromEnvironment() => string.Equals(
    Environment.GetEnvironmentVariable("TEMPORAL_TEST_ENV_CONFIG_SERVER"),
    "true", StringComparison.OrdinalIgnoreCase);

[jmaeagle99]

Does this need to be in the public API? It seems all of these are easily accessible by public consumers that they could do it themselves, if necessary.