Refactor package finders and add PyPI finders

🔬 : What does this MR do?

This is a refactoring of some of the package finders that will help form the foundation for adding group level PyPI support.

Currently, the logic for finding PyPI packages lives directly in the Grape API file as two helper methods. As we expand to add additional API endpoints, it will make more sense for this logic to have a dedicated set of finders. I originally planned on including these updates directly in the MR that implements group level support for PyPI, but it was getting a bit long, so I pulled this refactoring section out into it's own MR.

This MR creates Packages::Pypi::PackageFinder from #packages_finder and Packages::Pypi::PackagesFinder from #find_package_versions. You will see these two finders are set up to take a group or project in preparation for the updates to support groups in the API.

The Maven and NuGet finders are already very similar in structure to the new PyPI finders, so I've created an abstract class: Packages::GroupOrProjectPackageFinder for them all to inherit from. This also led to updating them to all have the same interface.

Unifying the structure of these finders allows the logic within each one to be simplified, and makes it more obvious what unique logic needs to be added for each package type. The hope is that in the future, more package types (such as npm and conan) may also be able to be refactored to a common interface.

💾 Database

Although this MR is updating a variety of finders, none of the queries are new or changing.

Does this MR meet the acceptance criteria?

Conformity

• I have included a changelog entry, or it's not needed. (Does this MR need a changelog?) Not needed due to pure refactoring
• I have added/updated documentation, or it's not needed. (Is documentation required?)
• I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?)
• I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?)
• I have self-reviewed this MR per code review guidelines.
• This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines)
• I have followed the style guides.

Availability and Testing

• I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
• I have tested this MR in all supported browsers, or it's not needed.
• I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.

Related to #225545 (closed)