Fix package installer tests

[marcpopMSFT]

Revert my prior change that removed the package installer tests from configuring the nuget cache.
The actual issue is that helix machines are reused without a full reimage. This means that the caches from prior runs are still configured in nuget but the folders may not exist anymore (causing these tests to fail).

This is an alternative solution of adding a nuget.config file to the folder that dotnet is being run from. Alternatively, we may need it at the root of the test folder itself but from viewing output, there is already one there that runs a clear and likely isn't being picked up.

[marcpopMSFT]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[joeloff]

This still just keeps adding sources, correct? So eventually an agent could run out of disk space if they are not removed?

[marcpopMSFT]

FYI, I ran the tests locally and confirmed that a nuget.config file in the location of the dotnet test execution successfully works here (or at least a bad one causes the same failures and if there's a bad global config, it fixes the tests).

[marcpopMSFT]

This still just keeps adding sources, correct? So eventually an agent could run out of disk space if they are not removed?

@joeloff , this adds the source to a local nuget.config file that exists for this particular test run and is not persisted between runs as far as I know. For example, I dug up the logs from one test in this run and you can see that the script is running in a random directory name.

The way I had it before was adding to the global nuget config which could eventually run out of space if the computer weren't reset (though I don't think helix machines would last that long).

C:\h\w\A4C7090B\w\AC500943\e>dotnet new nugetconfig 
The template "NuGet Config" was created successfully.

C:\h\w\A4C7090B\w\AC500943\e>dotnet nuget add source C:\h\w\A4C7090B\p\d\.nuget --configfile nuget.config 
Package source with Name: Package source 1 added successfully.

A different test for this same PR ran in a different directory. It looks like helix creates one random directory name per PR and then another random directory name for the test itself.
C:\h\w\A4C7090B\w\A11F0918\e