Deprecate passing extra parameters to __construct() to prepare for 3.0.x

Problem/Motivation

As the module evolves, we can expect new services to be added, service dependencies to change, etc.

The "classic" way to inject dependencies into a class is to use arguments to the constructor (i.e.: public function __construct($dependency1) { $this->dependency1 = $dependency1; }. But if you want to add a new dependency, or delete a dependency, then you have to change the function signature of the constructor (which is often public).

Technically, Drupal core's backwards-compatibility policy considers service object constructors to be @internal; however, in practice, changing the signature of service object constructors can occasionally cause fatal errors after a module upgrade, which isn't ideal.

Fortunately, PHP provides an alternate way to inject dependencies that doesn't involve changing function signatures, and thus avoids fatal errors on module upgrades...

class Foo {
  /* Omit the constructor, i.e.: to inherit it from its base class */
  public static function create(ContainerInterface $container) {
    $instance = new static():
    $instance->dependency1 = $container->get('dependency1');
    return $instance;
  }
}

... to distinguish these from the classic-style of dependency injection, this issue will refer to this as the "new-style of dependency injection".

At time-of-writing, the 2.x branch of structure_sync has 4 instances of classic-style dependency injection:

1. \Drupal\structure_sync\Controller\MenuLinksController::__construct()
2. \Drupal\structure_sync\Form\BlocksSyncForm::__construct()
3. \Drupal\structure_sync\Form\MenuSyncForm::__construct()
4. \Drupal\structure_sync\Form\TaxonomiesSyncForm::__construct()

There is talk of creating a 3.0.x branch in #3517435: Drop support for D8, D9, D10.0-10.3.

We can't change constructor signatures in the 2.x branch; but we can prepare to change the signatures in the 3.0.x branch by deprecating the use of classic-style dependency injection.

Proposed resolution

For the 4 services listed above...

1. start using the new-style dependency injection for those services; and;
2. stop doing anything with the parameters passed into those constructors, and mark those parameters as deprecated

... this will allow us to remove those constructors in a 3.0.x branch.

Remaining tasks

1. Write a merge request to start using new-style dependency injection and deprecate classic-style dependency injection in the 2.x branch
2. Review and feedback - by @spiderman in #4
3. RTBC and feedback - skipped; maintainers worked on this issue
4. Commit
5. File a follow-up ticket for the 2.x branch to deprecate the constructors in BlocksController, TaxonomiesController, and (soon to be) MenuLinksController - by being consistent about how we refer to $this->config, and $this->entityTypeManager, we could get rid of the rest of the code in those controllers - #3519479: Deprecate the constructors in BlocksController, TaxonomiesController, and MenuLinksController
6. File a follow-up ticket for the 3.0.x branch - #3519483: Remove constructors and extra constructor parameters from Controllers and Form classes
7. Release a 2.0.9 version - Deferred for #3519479: Deprecate the constructors in BlocksController, TaxonomiesController, and MenuLinksController

User interface changes

None.

API changes

None.

Data model changes

None.