Add list generic package version/file API endpoint

[imgurbot12]

Resolves #35762

Introduces a new generic package api endpoint that allows an authorized user to list/enumerate uploaded packages under a specified organization and package-name.

This is useful for linking gitea's generic package registry with additional automation that can operate using the content uploaded here - particularly when combined with ci/cd actions - for example automatically downloading and deploying the latest compiled build of repos within your organization.

The API itself is intended to be as simple and straight forward as possible; only returning the most relevant information pertaining to the versions/files available.

NOTE: the contributing guide mentions that all new APIs should be documented using swagger docs, but I noticed that none of the package APIs include any swagger-docs, so I wasn't sure what the preference on implementation there would be.

Example usage:

$ curl http://localhost:3000/api/packages/TestOrg/generic/examplePackage/list
[{"version":"v0.1.0","downloads":0,"files":[{"name":"example.tar.gz","created":1761612511}]}]

[lunny]

It's better to have a test

[imgurbot12]

It's better to have a test

@lunny tests added as requested. I hope that covers what is expected, lmk if we need any additional tests.

Not sure why the mysql integration tests failed, considering the ones that I added seemingly passed successfully. It seems like it just randomly crashed at the end for some reason.

edit: nvm i cant read. looking into it. weird it was only mysql lol

[imgurbot12]

looks like it was an issue with mysql returning the objects from the database in a different order than all the others did. have no idea why, but I'll add a sort to the unit-test that way its consistent for the test.

[imgurbot12]

all tests passing now! :)

[lunny]

Please run make genearte-swagger to update swagger files.

[imgurbot12]

Please run make genearte-swagger to update swagger files.

@lunny I just ran it, but it did not generate any new files or make any changes to the repo. I don't believe any of the /api/project/ apis are documented via swagger. only /api/v1 which are different.

That's why I included my note in the original PR message:

NOTE: the contributing guide mentions that all new APIs should be documented using swagger docs, but I noticed that none of the package APIs include any swagger-docs, so I wasn't sure what the preference on implementation there would be.