Since you can now include arbitrary files from any package by just adding the `PackageReference` metadata attribute to packed items, we just turn on the `GeneratePathProperty` metadata for all `PackageReference`s by default, since that only incurs minimal overhead in that it will create a new `PkgPACKAGE_ID` property on nuget restore, but that's about it.

Fixes #35

When packing a package reference with PrivateAssets=all, you typically
do so in order to run the resulting code from the target pack folder
directly without having any extra dependencies that have to be resolved
from elsewhere. For this typical use case, you'll want to pack actual
"runnable" assemblies, not reference assemblies.

Packages that pack reference assemblies (typically done for netstandard)
resulted code that couldn't run because the packed assemblies contained
no code.

So we first look at related files that have a "/ref/" in the path, see
if we can find the same file but under "/lib/" and if so, pack that
instead.

Fixes #36

Sometimes it may be useful to just pack the top-level dependency from a reference (i.e. you're getting the other deps by some other means, or the environment they run on doesn't require them, such as for Microsoft.Build.Framework, say).

This allows just setting PackTransitive=false to stop the transitivity.

Fixes #37

Dev > Main

Because we were importing the compatibility props only from the non-multitargeting targets, the defaulting of PackOnBuild from GeneratePackageOnBuild was not being applied and that caused usage of that property to fail in multi-targeting projects.

By bringing in the compat props from the shared targets (used in both single and multi targeting scenarios), we can properly default all values in all types of builds.

Fixes #34

SDK pack defaults the package description to the string Package Description if none is provided.

Do the same in nugetizer so that installing the package doesn't start failing for packages (maybe internal?) where a description isn't provided.

Fixes #40

When MSBuild project references are resolved, in multi-targeting P2P references, the `SetTargetFramework` metadata is populated with the nearest target framework supported by the referenced project (from the referencing project's point of view). For example, if a `netcore3.1` project references a `net5.0;netstandard2.1` one, when resolving the contents for the referenced project, the built-in targets will properly calculate (using the NuGet-provided GetReferenceNearestTargetFrameworkTask task) the target framework compatible with the referencing project.

If we don't set the target framework, we end up inadvertently invoking targets on the project reference using the *calling* project target framework (in this case `netcoreapp3.1`), which is not supported by the referenced project and we end up with a missing MSBuild target import (since NuGet conditions the .props/.targets imports to the target framework), and it ends up manifesting itself as an error that the reference hasn't been nugetized, when in fact it's because we're invoking with the wrong TF.

Fixes #27.

We already add `GetTargetPathWithTargetPlatformMoniker` for multi-targeting, but `GetTargetPath` is probably more common, so we add it with the same pattern used in the built-in targets.

This makes it behave just like PackagePath/PackFolder, and avoids having to explicitly add `Pack=true` after you specified `PackageReference`.

For example:

    <None Include='lib\netstandard2.0\Newtonsoft.Json.dll' PackageReference='Newtonsoft.Json' />

Will now automatically be packed. The existing inference rules about target path/package path still apply, and in this case it will mean the file is packed to the same relative path as the referenced file in the source package reference.

Fixes #44

No need to set PackNone=true if PackageReference is set on a None item

Remove Discord option for now

The microsoft/setup-msbuild@v1 action does not seem to work for bash CLI :(