Makes page header block lede rendering slightly more flexible

[ctorgalson]

• Retains current rendering, but anticipates that the {{ lede }} render array could have a different structure.
• A forthcoming change to localgovdrupal/localgov_guides may require this.
• See: 122 consider stacked h1 pattern for guides localgov_guides#133
• Re: 491-localgov_base-directly-access-value-property-of-lede-in-localgov-page-header-blockhtmltwig

[finnlewis]

Thanks for this @ctorgalson

Discussing in Merge Monday and think we need some input from Mark and perhaps look for consistency in the approach between guides, step-by-step and publications.

In localgov_publications we've gone the NHS route: https://github.com/localgovdrupal/localgov_publications/blob/1.x/templates/localgov-publication-page-header-block.html.twig#L20-L31

Be interested to hear from @markconroy on this too.

[andybroomfield]

Ref, also maybe a third option localgovdrupal/localgov_core#192

[markconroy]

I'm not fully sure of the problem being solved, but from a code perspective this looks "good enough for now; safe enough to try". We can create a follow up if we want/need to so that we have a unified approach to these type things.

[ctorgalson]

@markconroy The idea is to make localgov_base less reliant on a render array with a specific structure.

Changes to localgov_guides may change the array, but it's already possible for any sub-theme or module to preprocess lede into something that doesn't have a #value property.

[finnlewis]

Just discussing in Merge Monday.

Andy mentioned localgovdrupal/localgov_core#193 which I see you have comment on @ctorgalson

I also see localgovdrupal/localgov_guides#133 (comment)

So.... actually this makes sens for now. @markconroy is happy to merge this for now, making the $lede variable more flexible in localgov _base.