Improve Chocolatey setup as administrator and add Test-AdminRights helper

This expands upon GH-453 by supporting the scenario where UAC is enabled but Chocolatey installer is running with administrator rights (i.e. from an elevated shell).

First commit adds a couple of helper functions that make it easier and safer to write tests altering the environment.

Commits 2 and 3 introduce **tests for Chocolatey installation**, assuming running with admin rights, but with UAC enabled (i.e. the default case on my system).
Commit 4 introduces tests for scenarios with UAC disabled. It is done by temporarily (for the duration of each test case) adjusting the UAC setting in the registry. Such a change does not take effect until the system is restarted, but Chocolatey code that tests UAC status is fooled.

Next two commits add a **helper, Test-AdminRights, that implements the logic to check if current user identity is a member of the Administrators group**. Apart from the obvious DRY benefit of centralizing that logic in one place, this also makes it possible to mock that test and simulate standard user scenarios even when running with administrator rights (as the test suite is run).
The mocking facility is implemented in the next commit, using a global variable to control whether the helper should return the truth or a fixed answer. Ugly, I know, but the only way I found that would work while testing Chocolatey installation (the installer explicitly imports the helpers, so Pester mocks get overridden).

With admin rights mocking infrastructure in place, it is now possible to test Chocolatey installation in standard user scenarios (commit 8).

Commits 9 and 10 implement (TDD-style) the gist of this PR. Namely, **if Chocolatey installation is performed with administative privileges, environment variables are set at Machine scope**. UAC status is irrelevant, only the actual rights of the process matter.

Since UAC statuc is no longer a factor influencing Chocolatey behavior, the last two commits remove the UAC mocking facility and eliminate duplicate tests.

Incidentally, in-depth testing of Chocolatey installation uncovered some cases (marked with comments in the tests), where the installer behavior with respect to environment variables is, in my opinion, suboptimal. I will bring those issues to discussion separately, once this PR is verified and accepted.
If we could find a way to mock out the actual calls to the system and test the behavior of chocolatey based on what is returned from those calls, I think we can call these unit tests.

Actual hits to the system are considered physical integration tests and should probably be moved somewhere else.