Fix MenuLinkInterface::isCacheable(): remove it in favor of implementing CacheableDependencyInterface

The one instance that we used to have that used isCacheable() { return FALSE; }:

/**
 * Provides custom logic for the user.page menu link.
 */
class MyAccountMenuLink extends MenuLinkDefault {

  /**
   * {@inheritdoc}
   */
  public function isEnabled() {
    // The path 'user' must be accessible for anonymous users, but only visible
    // for authenticated users. Authenticated users should see "My account", but
    // anonymous users should not see it at all.
    // @todo Re-write this as a link to entity.user.canonical with dynamic route parameters
    //   to affect access since hidden should not be dynamic.
    //   https://www.drupal.org/node/2306991
    return $this->pluginDefinition['enabled'] && !\Drupal::currentUser()->isAnonymous();
  }

  /**
   * {@inheritdoc}
   */
  public function isCacheable() {
    return FALSE;
  }

}

(Was removed in #2294571: Redirect anonymous users to login page from an exception listener instead of in MaintenanceModeSubscriber and restrict access to the my-account link to authenticated users.)

First and foremost: then we still have the problem that it's not clear the cacheability of what exactly is being described: only URL properties, or also menu link tree properties (such as whether it is enabled, expanded, resettable, deletable, translatable, the parent, the menu name)?

Let's assume we want to retain cacheability metadata.

Then opt-in means we have the situation that we have with AccessResult: code will assume the typical case, and ignore the other.

For access results, the typical case is that CacheableDependencyInterface is implemented. Which means it's easy to forget that not all of them implement it.

For menu links, if we do this, the typical case will be that CacheableDependencyInterface is NOT implemented. Which means it's easy to forget that sometimes, it may be not cacheable. But, in this case, very, very few things will ever interact with MenuLinkInterface objects, so the potential damage here is much lower.

Still, wouldn't it then be better to then just always implement CacheableDependencyInterface? That's more consistent. MenuLinkBase is used by all menu link plugins anyway (at least in core), so the DX impact will still be zero.

First, let's prove by simply removing it that zero test coverage exists for this.

The "first" only meant "as a first step in this issue".

Let's continue the discussion.

It's easy to support CacheableDependencyInterface, but it will remain very confusing IMO. Nevertheless, there *are* use cases.

We just have to make a choice.

Done.

This will be utilized during menu rendering in #1805054: Cache localized, access filtered, URL resolved, and rendered menu trees; it's much easier to add support for it there than here, so let's do it there. This was not yet being used anywhere, nor tested anywhere anyway (as demonstrated in #8), so this does not represent a regression.

CR filed: https://www.drupal.org/node/2482623