Add support for the `repository` property in .nuspec

Support for a `repository` property in NuGet `.nuspec` files [was added a while back](https://devblogs.microsoft.com/nuget/introducing-source-code-link-for-nuget-packages/), with the idea being that this would make tracking both the project's website (using the existing `projectUrl` property) and the package's source code (using the new `repository` property) clearer.

Chocolatey already had the `packageSourceUrl` property to achieve this.

However, some package repositories, such as GitHub Packages, will now not allow packages to be uploaded without the `repository` property being set in the `.nuspec` file:
```
WARNING: No destination repository detected. Ensure the source project has a 'RepositoryUrl' property defined. If you're using a nuspec file, ensure that it has a repository element with the required 'type' and 'url' attributes.
```

I believe this leaves 4 options:

1. Add support in `choco pack` for the `repository` property alongside the existing `packageSourceUrl` property.
- Backwards-compatible, and allows GitHub Packages to be used as an package repository.
- Will lead to duplicated properties if used (i.e. the `repository` property and the `packageSourceUrl` property would be set to the same value).

2. Automatically transform the existing `packageSourceUrl` property into the `repository` property in `choco pack`'s generated `.nuspec`.
- Not backwards-compatible, will cause existing tools that depend on `packageSourceUrl` to break.
- Cleaner than option 1 - no duplicate properties.

3. Require the `repository` property to be used in `.nuspec` files rather than the `packageSourceUrl` property.
- Not backwards-compatible, publishers will have to update their `.nuspec` files.
- Existing tools that depend on `packageSourceUrl` will have to check for the `repository` property first, then fallback to using the `packageSourceUrl`.

4. Do nothing
- Prevents GitHub Packages and possibly other package repositories that use the [current `.nuspec` specification](https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Packaging/compiler/resources/nuspec.xsd) from being used.
- Divergence between NuGet `.nuspec` files and Chocolatey `.nuspec` files. Whilst they are different tools, given that Chocolatey leverages NuGet package repositories, I think as much compatibility as possible should be the goal?

Happy to contribute, but I think this requires input from others before making PRs and changes.

First resolve which of the four compatibility options maintainers want; the issue does not identify a chosen behavior. Then trace the choco pack entry point and its generated .nuspec output, using the existing packageSourceUrl behavior as the comparison point. Done means the agreed repository handling is implemented and its compatibility implications are covered.

Written by the indexing model from the issue text.