State how payment details modifier data is serialized and used

[domenic]

This closes #346, by making it clear that the data is serialized and stored in the PaymentRequest for further usage by show(), and closes #307, by finally stating all the points at which JSON-serialization happens explicitly.

A couple of points worth mentioning:

• I assumed we wanted the same swallow-all-exceptions behavior for updateWith for the JSON serialization process there.
• It's still a bit vague exactly what data is to be sent to the payment app by show(). I put in a sentence "The payment app should be sent the appropriate data from request in order to guide the user through the payment process. This includes the various attributes and internal slots of request." This is meant to convey how the data is transported. But getting this fleshed out in more detail would probably be a good idea.

[marcoscaceres]

I assumed we wanted the same swallow-all-exceptions behavior for updateWith for the JSON serialization process there.

Yes, that seems fine.

It's still a bit vague exactly what data is to be sent to the payment app by show(). I put in a sentence "The payment app should be sent the appropriate data from request in order to guide the user through the payment process. This includes the various attributes and internal slots of request." This is meant to convey how the data is transported. But getting this fleshed out in more detail would probably be a good idea.

I think this is pretty good, and we should flesh it out if ambiguities comes up during implementation, testing, and usage. It maybe "good enough"(tm) to not cause interop issues.

[marcoscaceres]

LGTM, bar nit.

[marcoscaceres]

nit: link to <a>[[\serializedModifierData]]</a>. I'll eventually teach ReSpec about internal slots :(