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.
I implemented a very thin abstraction layer, wrapping [Environment]::Get/SetEnvironmentVariable and obtaining a list of environment variable names (needed by one helper). In test code I can now replace that layer with mocks that read and write in-memory state.
I've left the existing backup/restore mechanism in place, first to protect against bugs and code not going through my layer (no such code now, but someone might forget and write a direct call to [Environment] in the future), second to restore process-level environment between test cases.
The restore mechanism will now warn if it detects a change at user or machine level, because that means some code did not use the layer and should be fixed.