Rename composer package class

What does this MR do and why?

Rename Packages::Composer::Package to Packages::Composer::Sti::Package. Packages::Composer::Package will be used to link to packages_composer_packages table at the later stage.

I've considered different options on how we could get two tables work together and, I think, that the approach with two different models has the lower risk and most straightforward. The analysis of different approaches may be found here.

A glimpse of how two classes Packages::Composer::Sti::Package and Packages::Composer::Package can live temporary together is here.

References

Foundation: Prepare application code to read fr... (#548761 - closed)

Screenshots or screen recordings

No.

How to set up and validate locally

Publish Composer package

1. Create a project and composer.json to it:

   composer.json

   {
     "name": "user/madrid",
     "autoload": {
       "psr-4": {
           "User\\Madrid\\": "src/"
       }
     },
     "authors": [
       {
           "name": "User"
       }
     ],
     "require": {}
   }

2. Add a tag. For example 1.0.0

3. Publish a package

   $ curl --fail-with-body --data tag=<tag> "https://__token__:<personal-access-token>@gitlab.example.com/api/v4/projects/<project_id>/packages/composer"

4. Verify that the package was successfully published.

5. Install composer package docs

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #548761 (closed)