Improve Landing Page module performance

Problem

The landing page module performed quite a bit of preprocessing that could be handled by Drupal instead. Simplifying these methods or removing them altogether reduces the amount of code that is created and simplifies caching by producing less data in more centralised locations.

Solution

Remove config load from LandingPageConfigOverride

We now know how to use the NestedArray::mergeDeep properly to add new items to an array without loading existing configuration. This speeds up config overrides slightly.

Use variables instead of route parsing

The current node is already present in the `$variables` that is passed to the preprocess hook. It's cleaner (and more stable and performant) to use this value instead of trying to parse the value from the URL and load it manually.

Replace preprocess hook by display mode change

The Drupal display modes have the possibility to show fields as URL. This mode still allows you to select a image mode. Using this method removes to need to add a custom variable to a template through a preprocess hook. This method is also more easily customised.

**BREAKING CHANGE**: Because a value is removed from a template.

Remove node_edit_url from paragraph hero's

The variable isn't actually ever set for paragraphs and is probably a copy paste error from another hero template.

**BREAKING CHANGE**: In case the variable was used in an extending project

Change node_edit_link to render array

The preprocess hook does not need to check what page it's on because it's not called for the edit or delete page.

This commit also changes the way the URL is rendered to use a render array. This causes less operations in the twig template (if statement, string append etc.) and allows the node edit URL to do its own access checking instead of doing this in a preprocess hook.

Use NodeInterface instead of Node for argument types

Something can be created that implements the NodeInterface type, which we can process, but is not a Node.

Additionally, the `instanceof` check is not needed because this is guaranteed by our function argument type.

Add landing page hero image field

This field will be used to store the image that is used for featured landing pages. This allows the featured image to be calculated when the node is saved instead of when it is viewed. This should speed up viewing performance (which is the majority of the use-cases).

Replace _social_landing_page_get_hero_image with pre-calculated image field

This commit uses the newly added field_landing_page_image to provide a teaser image for landing pages. This improves the view performance by moving the calculations for which image to display into the saving of the entity instead of during every display.

The added benefit of using a standard name of field_{node_type}_image allows code to be simplified by removing special casings that were added for landing pages where this field was not yet available.