Add a metadata field

[dbrain]

Gives up and adds a generic meta field to envelopes for consumer specific details. Expectation is that the core spec is used to be "renderable" correctly for all implementers, while "meta" provides additional context for specific callers.

For example Such accepts payments for two different modes of payment request and wants to render the payment screen slightly differently to highlight the fields that are the most relevant to the thing being paid. Sometimes order_reference should be the "loud" thing, other times vendor_order_id should be the loud thing depending on payment type.

aka the "stop the app developers finding hacky fragile ways to make this happen within confines of spec" button.

Purposely just a minimal "oh btw this exists" field in in the schema ref rather than writing Anne of Green Gables to justify it's existence in the larger doc, it's the "last resort if you really need some specific information to hit your specific consumer and don't expect anyone else to care about it" lever.

[dbrain]

@raffecat Mind having a poke at this? Place for the hod_invoice_id we talked about, in spec rather than "off spec" so it doesn't force clients to do any kind of specific serde of the envelope (i.e. a generic DogeConnectEnvelope could be used instead of DogeConnectEnvelopeWithHackyInvoiceField).