Feature request -{site.message_header} (was {domain.logo})

This issue description has been updated to reflect the 5.76 implementation. The original issue is at the end.

After much discussion this issue has settled on implementing the {site.message_header} token & a mechanism for other {site.x} tokens that can be user configured.

This is per 30451 - which adds a new table for storing site tokens (civicrm_site_token) with a corresponding entity and api.

• user documentation
• The PR adds the new token to all default message templates, which will allow some sites to un-customise their message templates, if they configure it
• Limited testing has been done on multisite configurations but the implementation is intended to make the tokens domain specific

I am planning to merge the PR in it's current state (after checking it runs) and recording follow up actions required/desired here

• documentation
• important - check the site header token is created in the install sql (it wasn't before I did regen)
• important Further validation on the form- 1 of the 3 items should be covered here https://github.com/civicrm/civicrm-core/pull/30530
• Fix the url to follow our multilingual methodology (which I don't know off the top of my head
• Add a pre-upgrade message telling people about the feature
• Write a blog post, telling people about the feature (this might also highlight the new diff feature in message-admin extension with the screenshots)
• Put the permissions into CRM_Core_Permissions so they apply to the api as well
• Do some testing around the multidomain aspect - preferably with a unit test but at a pinch @jtwyman might help with some testing on AUG
• Add some code comments into the site tokens to bring people back to this issue when they start to think about recursive token rendering
• Put some more thought into recursive token rendering - I feel like it might not be that hard but sane caching might be - also it gets harder when we pass through context {contact.id} vs it we just allow site tokens - but I feel like the value really amps up when you can add a block with contact related tokens into (e.g) an email a user it composing.
• Unit tests - see this comment for discussion of what / how to add
• Consider also adding {crmPage} smarty function - discussed further down in this issue and inspired in part by Pretty Workflow Messages
• Think about how pretty message templates handles style tags - perhaps we should think about at least encouraging these in site tokens?

== ORIGINAL ISSUE === Tim & I discussed the other day adding the {domain.logo} token. As always when this comes up we started with 'it would be very easy to do this minimal version' and by the end of the discussion the scope was un-manageable as unsponsored work.

However, I think the thing we CAN do is document it....

The easy way

{domain.logo}

refers to the image (if any) in the image_url field for the domain contact. That's it.

Probably we would need a version with <img> tags & one without.

But then ... sizing & ^^ is too basic/ limited So next most complex is to use a setting. Once we start down this path we wind up having to develop a UI, handling sizing and it seems we might as well skip to....

Mailing Component tokens In this version we would add a new component type to civicrm_mailing_component and rows of this type would be available as tokens using {domain.{civicrm_mailing_component.name}}. Placeholders ones for '{domain.logo}' and '{domain.header}' would be added. The existing UI could be used.

And still spiralling

• from there we got into trying to make it possible to nest the above, to use regions, to do the sort of thing the entity_messages token attempted to whereby we could store entity-related snippets (the idea was both to be able to insert a contribution specific block and to store entity-specific text to re-use - e.g to re-send an invoice with the original form-base message text)