use $.job.credentials-metadata if $.credentials isn't given

[brettfo]

This PR is for a very specific scenario, namely:

1. A repo with NuGet packages
2. That depends on a custom password- or token-authenticated feed
3. And no NuGet.Config file exists in the repo

The NuGet updater relies heavily on native NuGet tooling and the native NuGet tooling looks in parent directories for a NuGet.Config file and also in the user-level location of ~/.nuget/NuGet/NuGet.Config.

In this case a custom package feed needs to be added to the user-level NuGet.Config file so that all of the tooling knows it's available. The proxy service is then responsible for all authentication.

Details

Update jobs are split into two phases, fetch_files and update_files. Each job phase is given different information regarding feed credentials as specified in the job file.

The fetch_files step passed along the root property credentials which may contain secrets (but probably not given the last few months of updates and the push towards using the CLI) and the update_files step passed along job.credentials-metadata which is identical to the other property, but with all secrets removed.

The NuGet updater needs feed information for the fetch_files step, but running with a job file like this:

job:
  # some values here
credentials:
  - type: nuget_feed
    # some other values

resulted in fetch_files getting an empty array because no secrets are passed to this step of the updater; the proxy is expected to handle it.

The fix is to allow the file fetcher command to fall back to the secret-less credentials-metadata so that the feed URLs can be passed on. The end result is that the native NuGet tooling will see package feeds listed in the user-level NuGet.Config and honor those for all update operations.

The generation of the user-level NuGet.Config was also updated to always include a reference to api.nuget.org. This was done because in the scenario covered here, the lack of a NuGet.Config file in a repo, or the lack of a <clear /> directive indicates that the owners of that repo are expecting higher-level implicit feeds to be used and the only common higher-level implicit feed is api.nuget.org. This won't break other scenarios where repo owners explicitly don't want api.nuget.org because they will have already specified the <clear /> directive which will exclude everything in the user-level file anyway.

Fixes #11690

[randhircs]

I approve it.