fix: convert PaymentMethodData.data

[marcoscaceres]

Closes #813

Part 1 of #753

Converts PaymentMethodData.data to IDL type or object.

The following tasks have been completed:

• [X] Confirmed there are no ReSpec errors/warnings.
• [X] Modified Web platform tests
• [X] Modified MDN Docs - obscure detail, not required.

Implementation commitment:

• [ ] Safari
• [x] Chrome - Implemented
• [x] Firefox - Implemented
• [ ] Edge (public signal)

Optional, Impact on Payment Handler spec?

---

Preview | Diff

[marcoscaceres]

Both Chrome and Firefox do the IDL conversion already.

[marcoscaceres]

@domenic hopefully good now.

[marcoscaceres]

@domenic, because in implementations, PaymentMethod.data's JS-to-IDL conversion happens in the PaymentRequest constructor (instead of on .show()), it means we don't need the [[serialized*]] data internal slots because:

• We can do the "JSON serializable" check at construction time and when updateWith() is called: this gives us assurances that .data doesn't contain any un-serializable JSON types and circular references....and, if ever needed, .data can be serialized to a string in the future.
• And because of the above, we can just internally hold converted IDL values for each PaymentRequest instance, without the need to hold them in string form.

This also fixes what would otherwise be a mess when show()ing or updateWith()ing a payment sheet: the [[serializedModifierData]] array positions would need to match the position of the deleted .data members.

So, with this PR, when a payment handler shows or gets updated, it always operates on its expected IDL type, without needing to redo any redundant JSON parsing, re-conversions, etc.

[marcoscaceres]

Went back to look at https://github.com/w3c/payment-request/issues/346 ... I'd forgotten that the ideas was to support actually sending the JSON-serialized data no just across process boundaries (which I was imagining was just as per-origin process isolation) - but to other native applications acting as payment handlers.

As such, I concur that it still makes sense to keep the JSON serialization.