Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/
Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds

There is a Package Substitution Attack inherent in NuGet, whereby
if multiple package sources provide packages with the same name,
it is *indeterminate* which package source will provide the package.

For example, consider the [`XliffTasks` package][0], currently
provided from the [`dotnet-eng`][1] feed, and *not* present in the
NuGet.org feed.  If a "hostile attacker" submits an `XliffTasks`
package to NuGet.org, then we don't know, and cannot control, whether
the build will use the "hostile" `XliffTasks` package from NuGet.org
or the "desired" package from `dotnet-eng`.

There are two ways to prevent this attack:

 1. Use `//packageSources/clear` and have *only one*
    `//packageSources/add` entry in `NuGet.config`

 2. Use `//packageSources/clear` and *fully trust* every
    `//packageSources/add` entry in `NuGet.config`.
    `NuGet.org` *cannot* be a trusted source, nor can any feed
    location which allows "anyone" to add new packages, nor can
    a feed which itself contains [upstream sources][2].

As the `XliffTasks` package is *not* in `NuGet.org`, option (1)
isn't an option.  Go with option (2), using the existing
`dotnet-eng` source and the new *trusted* [`dotnet-public`][3]
package source.

[0]: https://github.com/dotnet/xliff-tasks
[1]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-eng
[2]: https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops
[3]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-public

* Include Windows pdb in Nuget

* Bump version

* use a wildcard

* use a wildcard

* use RelWithDebInfo configuration for the build