fix: Ensure proper sequencing during initialization

[DaveTryon]

Details

Fix canary upgrade problem by ensuring that ordering assumptions are respected during initialization. For the autoupdate to work as expected, it's important that Container.SetAutoUpdateReleaseChannel gets called before Container.GetDefaultInstance. When #1204 was added, the code is in the proper sequence, and the upgrade works as expected when built for the debug config. When built for the release config, though, I was able to prove that the calls were occurring in the wrong order. It seems that the optimizer decided to change the sequence of calls between the API's, meaning that the autoUpdate code always loaded the production data.

The change here is to move the telemetry initialization code into a separate method so the optimizer can no longer change the call order. As an aside, enabling telemetry in a method called PopulateConfigurations was a bit off, so having it in a separate method is also better coding style. I included a comment in PopulateConfigurations as a reminder about the calling order dependency.

Motivation

Address #1226

Context

Pull request checklist

• Run through of all test scenarios completed?
• Does this address an existing issue? If yes, Issue - [BUG] Canary only updates to the latest prod release #1226
• [n/a] Includes UI changes?
  • [n/a] Run the production version of Accessibility Insights for Windows against a version with changes.
  • [n/a] Attach any screenshots / GIF's that are applicable.

Note: After the PR has been created, certain checks will be kicked off. All of these checks must pass before a merge.

[jalkire]

It would be nice if we could have a more robust way to avoid this risk in the future, but I can't think of any great options