Bugfix - Correctly match package names from local repos

[anamnavi]

PR Summary

There was a bug in how we parse out name and version information from package file names when performing search against local repositories.

If you have a package test and test.submodule` present in the local repository their files will look like this:

`test.1.0.0.nupkg`
`test.submodule.1.0.0.nupkg`

We used WildCardPattern class before, with pattern {packageName}.*" which would pick up both packages if package testwas searched for. The code logic then assumed the rest of the part of the name would be the version so it would search through both package names and try to parsesubmodule.1.0.0` into a version.

This fix uses Regex more accurately created for the package name and to expect a version right after the name, not text.

PR Context

Fixes #1641 #1648

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Documentation needed
    • Issue filed:
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary.

[alerickson]

Looks good, just added a couple comments

[alerickson]

It might be nice to add logging here saying no matches were found.

[anamnavi]

this condition just means that as we're iterating through the files, if a file's name doesn't match it'll be reflected as matches.Count == 0 or even as groups.Count == 0. So if we added logging here it may be a lot of logs. We do have a condition after this iteration of files completes, where if the package file path latestVersionPath is empty and not set then we write an error.