Response timeout could leave page/user in confused state.

From Gecko bug, spec says:

After the payment request has been accepted and the PaymentResponse returned to the caller but before the caller calls complete() the payment request user interface remains in a pending state. At this point the user interface ought not offer a cancel command because acceptance of the payment request has been returned. However, if something goes wrong and the developer never calls complete() then the user interface is blocked.

For this reason, implementations MAY impose a timeout for developers to call complete(). If the timeout expires then the implementation will behave as if complete() was called with no arguments.

Problem is that the you have a race condition:

1. the promise from fetch("/make-payment", {body: response.toJSON()}) may take longer to resolve than the payment sheet being presented (e.g., 5 seconds in Browser X).
2. As the payment sheet is shutting down due to a timeout, fetch() promise resolves successfully (the user has been charged!).
3. The merchant is now in an awkward position, having to inform the user that the payment actually went through... but unable to use the payment sheet to do so (i.e.,.complete() now just returns a rejected promise).

We might need a new event to notify the merchant if the sheet has shut down on them. Otherwise, they will try to .complete() and response will just return a rejected promise.

@domenic, @zkoch, @aestes, @adrianba, all, thoughts?

No implementation files or tests are named. Start by reading the cited Payment Request specification and tracing the timeout and complete() behavior described in the issue. Done means reaching agreement on how merchants are notified when the payment sheet closes before complete() and documenting the resulting API behavior.