setters and getters for injected services in plugins aren't necessary

SearchAPI plugins have a weird pattern for their injected services.

The __construct() method is not overridden, but instead create() calls setters on the returned object.

Eg in RenderedItem:

  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    /** @var static $plugin */
    $plugin = parent::create($container, $configuration, $plugin_id, $plugin_definition);

    $plugin->setCurrentUser($container->get('current_user'));
    $plugin->setRenderer($container->get('renderer'));
    $plugin->setLogger($container->get('logger.channel.search_api'));
    $plugin->setThemeManager($container->get('theme.manager'));
    $plugin->setThemeInitializer($container->get('theme.initialization'));
    $plugin->setConfigFactory($container->get('config.factory'));

    return $plugin;
  }

This then requires tons of thin setters like this:

  public function setCurrentUser(AccountProxyInterface $current_user) {
    $this->currentUser = $current_user;
    return $this;
  }

and for reasons which escape me, there are getters that guard against the service being set:

  public function getCurrentUser() {
    return $this->currentUser ?: \Drupal::currentUser();
  }

Several observations:

- The plugins all implement SearchAPI's ConfigurablePluginInterface, which itself inherits from core's ContainerFactoryPluginInterface.
- That means that the plugin manager will *always* instantiate a plugin by calling create() and passing in the $container. So the guarded getters are not necessary
- It would be simpler, and also in line with core's pattern for DI plugins, to get the services from $container in create(), and pass them in to an overridden __create(). There is then no need for setter methods.

Benefits of this would be:

- much less boilerplate code
- follow same pattern as core plugin types
- better DX