Document conan_package_name and correct the package versions object

What does this MR do and why?

Two changes to the packages API page, both about API::Entities::Package and the version entity under it.

conan_package_name is documented nowhere. It is exposed at lib/api/entities/package.rb:22 under if: ->(package) { package.conan? }, and it exists because the same entity redefines name as the recipe for a Conan package. So for one package type the name on this page does not mean what the rest of the page implies, and the field that carries the real name is absent.

Every example on the page is a Maven or npm package, so there was no example to add the key to without making it wrong. I added a sentence instead, next to the existing creator_id paragraph and in both places that paragraph appears, which is the pattern the page already uses for a field that needs a condition explained.

The versions example does not match what GitLab sends. API::Entities::PackageVersion exposes id, version, created_at, tags and pipeline. The example shows a pipelines array inside each version and no tags. There is no pipelines exposure on that entity at all, singular pipeline is a single object rather than an array, and tags is unconditional. Anyone writing a client against that example gets the shape wrong, which is how I came to look.

The deprecated pipelines on the top-level package is a different field, is still exposed, and I left it and its history note alone.

One thing I noticed and did not change, because it is a third subject and this page is long enough already: API::Entities::Package::Pipeline exposes eleven fields and the pipeline objects in these examples show eight, missing iid, project_id and source. Happy to send that separately.

I found this while adding conan_package_name, creator_id and versions to the Go API client, in gitlab-org/api/client-go!3052.

MR acceptance checklist

This change is documentation only. No endpoint, parameter or behaviour changes. I parsed every JSON block on the page after editing: all five still parse, and the version object in the "Retrieve a project package" example now has exactly the five keys the entity exposes.