Improve cacheability metadata

I've added a first stab at that. If reviewing please be aware that some of the changes are from 📌 Refactor building links render array into prevnext.service Needs review and any comments on those changes should be made on that ticket.

Also I thought I'd explain the latest commit (fc936c4eb444158c9d6c08f9849c8d639f67a032). Without that commit I think the caching is correct, but it adds the config:prevnext.settings cache tag to every single entity view, which means every entity view gets purged on any prevnext config change, regardless of whether it's using prevnext. To avoid that I removed the cache tag and instead explicitly flush the entity bundle tags when the module config changes. It might be overkill, but I felt guilty just adding the config cache tag to every single entity view (:

Thanks!

I would also consider this improvement if I understand correctly:

I noticed this at the end of prevnext.module:

/**
 * Implements hook_ENTITY_TYPE_presave().
 */
function prevnext_node_presave(NodeInterface $entity) {
  $config = \Drupal::config('prevnext.settings');
  $enabled_nodetypes = $config->get('prevnext_enabled_nodetypes');
  if (is_array($enabled_nodetypes) && in_array($entity->bundle(), $enabled_nodetypes)) {
    // We are saving a node of a type with prevnext enabled, so invalidate
    // all cached rendered output of other nodes of this type with our tag.
    Cache::invalidateTags(['prevnext-' . $entity->bundle()]);
  }
}

Why do we have to invalidate cache of all nodes of some type with prevnext?
Since the nid is fixed, shouldn't we invalidate only the previous and next nids?

1. in case the node was deleted/disabled we regenerate the next link on the previous nid and the prev link on the next nid
2. in case the node was inserted we generate the next link of the previous nid
3. in case the node was enabled we regenerate the previous link of the next nid and the next link of the previous nid.

Thanks @kopeboy!

The MR already removes the section at the end of the module, though note if I understand correctly the same thing will happen anyway due to Drupal core. \Drupal\Core\Entity\EntityBase::invalidateTagsOnSave() calls ::getListCacheTagsToInvalidate() which adds the tags ENTITY_TYPE_list and if there's a bundle ENTITY_TYPE_list:BUNDLE.

Rebased off 3.0.x, it no longer includes external code and is ready for review/merge. Thanks!