feat(packages): add ConanPackageName, CreatorID and Versions to Package

What does this MR do?

API::Entities::Package exposes three fields the Package struct does not carry, and one of them is only ever sent by an endpoint this library has no wrapper for, so both halves are here.

Read from gitlab-org/gitlab at commit e5d23f6d, the tip of master when this was written:

Field	Exposed at	Sent
conan_package_name	package.rb:22	on a Conan package, where name is the recipe and this is the package's own name
creator_id	package.rb:42	always, and null when a deploy token or job token created the package
versions	package.rb:62	unless: ->(_, opts) { opts[:collection] }, so on a single package and never in a list

conan_package_name is the one I would point at first, because this repository already knew about it: the fixture in TestPackagesService_ListProjectPackages sends "conan_package_name": "Hello" today, and there has never been a field to decode it into. creator_id is a pointer because GitLab documents it as null for a package created by a deploy token or job token, and zero would be a different answer.

versions needed the endpoint as well. Its condition is Grape's own collection option, which is set when an array is represented, so the two list endpoints this library wraps never send it and GET /projects/:id/packages/:package_id always does. That endpoint had no wrapper, so adding the field alone would have added a field nothing could ever populate. GetProjectPackage is the wrapper, and the route it uses, routeProjectsIDPackagesID, already existed for DeleteProjectPackage. PackageVersion is the Go shape of API::Entities::PackageVersion: id, version, created_at, tags and a conditional pipeline.

Each field is placed where the entity exposes it and no existing field moves.

One gap I found next to this and did not fold in, so this MR stays about one entity. API::Entities::Package::Pipeline exposes eleven fields and PackagePipeline carries eight: iid, project_id and source are missing. That struct is reached from three places, including the new PackageVersion.Pipeline, so it deserves its own change rather than a footnote in this one. I am happy to send it if it is wanted.

I found all of this while developing an MCP server on top of this library, https://github.com/jmrplens/gitlab-mcp-server, which reads these keys out of the raw response beside the SDK decode.

Is this a breaking change?

No. Three additive fields on one response struct, one new exported type, one new method on PackagesServiceInterface, and the regenerated mock that goes with it.

The interface gaining a method is the only part worth a second look: an outside implementation of PackagesServiceInterface would have to add GetProjectPackage. Every service interface in this library is in that position whenever an endpoint is added, and testing/packages_mock.go here is regenerated with the same mockgen invocation the file records.

How was this tested?

TestPackagesService_ListProjectPackages asserts ConanPackageName from the fixture key that was already there, and creator_id added beside it.

TestPackagesService_GetProjectPackage is new and covers the endpoint and the field that needed it: it decodes a versions array with its tags and its pipeline, and asserts the invalid-id and request-option error paths the other tests in this file assert.

go build ./..., go test ./... and golangci-lint run ./... all pass locally, and gofumpt -l reports nothing on the changed files, the regenerated mock included.

Related to #2300