MenuTreeStorage::rebuild() invalidates a cache tag for every menu on the site, not just the ones it rebuilds

The real cost shows up on a full cache clear; the volume of menu cache-tag invalidations causes a lot of DB writes. The extra query the fix adds is marginal by comparison.
I updated the IS to clarify.

The script below creates 10K menu links, simulating a large site with many menus (e.g. og_menu, group_content_menu, domain menus). Once populated, compare time drush cr between the two branches. The fix avoids ~10K redundant cache-tag invalidations on every rebuild. Numbers on my machine:
- without fix (main branch): 3.5s
- with fix (MR16126 branch): 1.8s

<?php

/**
 * Populates the site with many content-managed menu links to demonstrate the
 * cost of MenuTreeStorage::rebuild() invalidating a cache tag for every menu on
 * the site. rebuild() runs on every `drush cr`.
 *
 * Each link is a normal MenuLinkContent entity in its own menu, so it has
 * discovered = 0 -- exactly like the menu links a site (or og_menu) creates.
 *
 *   drush scr populate_menus.php     # create the links
 *   time drush cr                    # measure, on 11.x and on the fix branch
 */

// Number of content menus to create. Bump it to make the difference larger.
$count = 10000;

$storage = \Drupal::entityTypeManager()->getStorage('menu_link_content');

// Remove any links from a previous run first, so this is repeatable.
$ids = $storage->getQuery()
  ->accessCheck(FALSE)
  ->condition('menu_name', 'bench_menu_%', 'LIKE')
  ->execute();
if ($ids) {
  $storage->delete($storage->loadMultiple($ids));
}

$t = microtime(TRUE);
for ($i = 0; $i < $count; $i++) {
  $storage->create([
    'title' => 'bench',
    'link' => ['uri' => 'route:<front>'],
    'menu_name' => "bench_menu_$i",
  ])->save();
}
printf("Created %d content menus in %.0fs. Now run: time drush cr\n", $count, microtime(TRUE) - $t);

Sure, done, it's a bit redundant with the comment above anyway.