Refactor the block plugin type's use of config

Problem/Motivation

This is a followup on #1535868: Convert all blocks into plugins, and as such is postponed until that goes in.

There are a few related issues here, but all stem from the basic paradigm expressed in the ConfigMapper class, which is a plugin mapper added by the original blocks-as-plugins patch. The behavior at issue in that class is as follows:

class ConfigMapper implements MapperInterface {
  public function getInstance(array $options) {
    $config = config($options['config']);
    if ($config) {
      $plugin_id = $config->get('id');
      $settings = $config->get();
      $settings['config_id'] = $options['config'];
      return $this->manager->createInstance($plugin_id, $settings);
    }
  }
}

This means it expects calling code to provide a config key as part of the definition. It does so with the magic key in the options array called 'config'.

Note - that itself is somewhat opaque, but is also the way the plugins system is currently designed to work: because the MapperInterface only specifies the single $options parameter, it means all plugins kinda do their own thing with respect to how they inspect that array to figure out which plugin to get.

There are upsides and downsides to this:

• Pros:
  • It's REALLY convenient for API clients; all it needs is a config key, then one line of code gets back the appropriate plugin instance.
• Cons:
  • For anything that knows it needs to load multiple plugin instances - say, Displays which need to load multiple Blocks - it is impossible to implement any kind of batch-loading strategy that will minimize the number of queries to the config cache (something which is very much planned as a config optimization).
  • From a pure architecture point of view, this unnecessarily tightly couples any plugin type using this mapper to the config system.

These issues would be mitigated the config mapper was an optional convenience, rather than a hard requirement, as it is right now. Such a thing could be achieved by making the ConfigMapper more of an optional thing, for example by turning it into a Decorator - though that'd be harder since there aren't really many other standard mappers out there to decorate.

With respect to blocks in particular, there's the additional issue of block_load():

function block_load($plugin_id, array $conf = array()) {
  $manager = drupal_container()->get('plugin.manager.block');
  try {
    $block = $manager->getInstance(array('config' => $plugin_id));
  }
  catch (Drupal\Component\Plugin\Exception\PluginException $e) {
    $block = $manager->createInstance($plugin_id, $conf);
  }

This makes the decorator optional as i described above, but done outside of the manager and in a wrapper function. Kinda no bueno. Crell also raised objections to it on the basis that it assumes the case where config is injected is the fallback case, and does so via catching an error, which isn't cheap.

We should refactor block_load() at the least, and maybe ConfigMapper as well.

It's possible these things actually deserve a couple different issues, but let's start for now with this one follow-up.

Proposed resolution

Not sure yet. Let's discuss that here :)

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

None.

API changes

Depending on what we decide to do, this could require some simple, but widespread, changes to how blocks are loaded at various points in core.