Store message receipt informaition

Currently back office credit card payments offer a place to enter a receipt message, but only for ones that are expected to do an immediate payment as the receipt is calculated in the form process.

We are trying to remove form layer assumptions about whether a payment will complete in real time or not, so we need to look at a way to store this for all payments. 2 possibilities have been discussed previously, and I have a 3rd to propose.:

1) add a column to civicrm_contribution for receipt_message
This would allow initial sending & resending. It could be re-edited at the time of re-sending if needed.

2) create a scheduled activity to send the receipt at the time of pending-payment creation and look for this activity to complete (with associated sending action) at the time of completion.
I quite like the visibility of the activity - but if you want to resend the receipt later is the message available & does it matter

3) create a new table called civicrm_entity_message - this would hold
entity_table, entity_id, module, field, msg_template_id, is_active

In this case we would record
entity_table : civicrm_contribution
entity_id : contribution_id
function : invoice_receipt_message
msg_template_id: 89000

(we could either save text into this table or into message_templates - if the latter we need to hide some types of templates from the message_templates screens to avoid showing individual receipts).

The versioning on messages is not quite clear to me - ie. if you used the quick-action (which we can / should add to each line on the contribution tab on a contact record) 'sent receipt' - it would pick up the current receipt, if any. On the flip side if you go into edit it would load the existing message, but if you edited it it would disable? the existing message & save the new one as an additional row? or overwrite the existing message? since the message ?should? be recorded on the previous activity anyway?

In general I like this design better than adding another field to the civicrm_contribution table because it starts to open up a few other options

1) moving some of the message templates out of the event table - which would reduce the incidence of the width on the event table being exceeded (varchar columns size to the widest instance, the event table can 'break' in multilingual situtations).

2) it raises the question of whether a domain default e.g for pay_later text would be better stored here or as (yet another) setting

3) like per 2 - we might have a domain default for other bits of text eg.
invoice_header AND we could have a syntax for adding things from this table as tokens - we don't have to implement it all right now. We could possibly simplify code by automatically assigning all message_templates for a given entity & for the current domain to each form at the CRM_Core_Form layer.

4) It allows extensions to add new message_template 'fields' for various purposes without being yet another DB field.

5) If we get a UI or widget for this type of entity then it becomes quite re-usable. If you look at the above part about what happens when you change the message this also applies to, for example, pay later text or contribution_page receipt text you want to be able to select the text from the domain default, other saved variants or write a new one. You also want to be able to save & overwrite - possibly just disabling the previous. (perhaps an argument for created_date & modified_date on the table). Also possibly an argument for a is_entity_specific column which would indicate whether to present this option only for the given entity or any of the same type.