Derive block migration per theme and per block plugin type

As with #3097336: Improve the DX for migrating content entities: view modes, fields, formatters, widgets etc should be migrated per entity type + bundle, There is no reason to do this in core as you can't run the migrations separately anyway. I'm moving it to migrate_upgrade along with that issue.

#3171980: Menu migration should happen before block migration would be a good addition here, but here we could make it required!

1. +++ b/core/modules/block/src/Plugin/migrate/source/d7/BlockTranslation.php
   @@ -46,7 +65,7 @@ class BlockTranslation extends Block {
   -      ->condition('i18n_mode', 1);
   +      ->condition('b.i18n_mode', 1);
   

   Nice hardening.

2. +++ b/core/modules/block/src/Plugin/migrate/source/d7/BlockTranslation.php
   @@ -100,8 +127,12 @@ class BlockTranslation extends Block {
      public function getIds() {
   +    $ids['module']['type'] = 'string';
   +    $ids['module']['alias'] = 'b';
        $ids['delta']['type'] = 'string';
        $ids['delta']['alias'] = 'b';
   +    $ids['theme']['type'] = 'string';
   +    $ids['theme']['alias'] = 'b';
        $ids['language']['type'] = 'string';
        return $ids;
      }
   

   HUH! How did this source plugin work at all until now!

   This seems like very sensible and overdue hardening 👍

3. +++ b/core/modules/content_translation/migrations/d7_block_translation.yml
   @@ -53,6 +54,8 @@ process:
   +          navigation: system_menu_block:main
   

   👏 — these also exist in d7_block.

+++ b/core/modules/block/src/Plugin/migrate/BlockDeriver.php
@@ -163,7 +164,15 @@ class BlockDeriver extends DeriverBase implements ContainerDeriverInterface {
+        $migration_base_ids_which_may_need_content_migration = [
+          'd6_block',
+          'd7_block',
+        ];
+        $block_content_migration_dependency_is_required = $block_content_block_migration && in_array($base_plugin_definition['id'], $migration_base_ids_which_may_need_content_migration, TRUE);
         $derived_migration = $base_plugin_definition;
         $derived_migration += ['migration_dependencies' => []];
         $derived_migration['migration_dependencies'] += [
@@ -191,7 +200,7 @@ class BlockDeriver extends DeriverBase implements ContainerDeriverInterface {

@@ -191,7 +200,7 @@ class BlockDeriver extends DeriverBase implements ContainerDeriverInterface {
           unset($optional_migrations[$block_content_migration_optional_key]);
         }
 
-        if ($block_content_block_migration) {
+        if ($block_content_migration_dependency_is_required) {

In manual testing, this means that d7_block:bartik:block_content now gets a required dependency on d7_custom_block 👍

This was a bug in all preceding patches.

Manually tested, works great! 🥳

#3187263: Block configuration translation migrations should be defined in "config_translation", not in "content_translation" and #3189880: Use square brackets syntax in sql queries broke this between 9.1.7 and 9.2.0-rc1.

The patch does not apply because it is for Drupal core. If this is to be fixed in core, this issue needs to be moved back there. Otherwise, the patch needs to be for migrate_upgrade.

We aren't doing this in core. The issue was moved here intentionally, but yes, it requires a completely different approach to do it in this module.

#3209249: Fix spelling for 29 migrate translation related words conflicted with #21 in 10.2. Rerolled.