Various fixes to the PaymentRequest constructor

[domenic]

• Fixes PaymentRequest constructor validation ordering does not match Blink at all #373: align ordering of steps with Blink's implementation, except check for allowed-to-use first since that makes more sense
• Fixes A PaymentItem can't be a "valid decimal monetary value" #334: properly get the total.amount.value instead of pretending total is a string
• Fixes PaymentDetails may not have values present for various sequences, but the PaymentRequest constructor assumes that it does #333 and fixes A PaymentDetailsModifier may not have an additionalDisplayItems value present #335: do not assume various dictionaries are present
• Fixes part of "contains a value for" isn't defined for dictionaries #321: use proper dictionary terminology
• Ensures request.[[details]].shippingOptions/modifiers is always a sequence, instead of sometimes left as not present
• Fixes various algorithm structure and typographic issues

---

This is on top of #368 and #370 and can only be merged after them.

[marcoscaceres]

@domenic, this one also now needs rebase. So. Close.

[domenic]

Just hit refresh :)

[marcoscaceres]

ah 👍

[adrianba]

Is there a need to reorder the checks to align with Blink? I think this might make our implementation out of compliance with the spec. Need to check on the impact of this but would probably prefer we don't change ordering if we don't need to.

[domenic]

In general some ordering fixes would be good. E.g. the current spec splits up checking methodData into two locations of the algorithm, interspersing checks and processing of other arguments between them, which is just strange (and requires looping over the sequence twice).

If there's a different ordering to the top-level "sections" desired, that'd be fine too. But the grouping here makes more sense than the current spec.

In other words, this PR's ordering is:

• allowed to use check
• process payment methods
• process the total
• process displayItems
• process shipping options
• process payment details modifiers
• process error

Any reordering of these seems reasonable, although I think the allowed to use check should be first. But the current spec, which splits up several of these steps into two or three separate substeps which are then sprinkled around the algorithm, seems bad.

[marcoscaceres]

@domenic can you rebase?

I also think @domenic refactoring is an improvement here - if only from an editorial perspective. We can do any additional reordering after that.

[domenic]

@marcoscaceres done

[marcoscaceres]

@adrianba, want your ok to merge this (and that Edge is willing to make the necessary changes to implementation, if any).

[adrianba]

I can live with this.