Edits based on recent discussions and decisions (#80)

* (Deleted this edit by mistake before merged)

Redo section 10.3 intro based on 14 Dec discussion

* Edits based on recent changes and discussions

This was not a comprehensive review of the document. However, I
reviewed it in light of some recent decisions and did some updates:

* Given 4 January discussion about recommended payment apps, I reviewed
the text on that topic and made changes.
* I also cleaned up some text on registration given the new assumption
that registration IS a prerequisite for usage of a payment app that
conforms to this specification.
* It has also become clear that this specification is not designed to
address native payment apps, and so I deleted some text on native
payment apps, and also stated more clearly that those mechanisms lie
outside the scope of this document.
* IMPORTANT: It is my current understanding that a payment app
identifier will designate service worker code. Therefore, the spec now
says that; we’ll discuss whether this was the right edit at our 10
January call.
* I tried to reduce instances of the word “display” in light of recent
discussions about “enabling the user” rather than always talking bout
display of information. Nonetheless, some instances of “display” still
remain in the spec where they make sense.
* I added mention of HTTP Link headers for finding payment app manifest
files; we may or may not need that but I’m keeping this spec aligned
with the payment method stuff.
* I added mention of paymentRequestID and otherwise cleaned up
discussion of reconciliation.
* Now that we have canHandle I removed some other notes and provided a
forward reference to it.

* Edits based on recent changes and discussions

This was not a comprehensive review of the document. However, I
reviewed it in light of some recent decisions and did some updates:

* Given 4 January discussion about recommended payment apps, I reviewed
the text on that topic and made changes.
* I also cleaned up some text on registration given the new assumption
that registration IS a prerequisite for usage of a payment app that
conforms to this specification.
* It has also become clear that this specification is not designed to
address native payment apps, and so I deleted some text on native
payment apps, and also stated more clearly that those mechanisms lie
outside the scope of this document.
* IMPORTANT: It is my current understanding that a payment app
identifier will designate service worker code. Therefore, the spec now
says that; we’ll discuss whether this was the right edit at our 10
January call.
* I tried to reduce instances of the word “display” in light of recent
discussions about “enabling the user” rather than always talking bout
display of information. Nonetheless, some instances of “display” still
remain in the spec where they make sense.
* I added mention of HTTP Link headers for finding payment app manifest
files; we may or may not need that but I’m keeping this spec aligned
with the payment method stuff.
* I added mention of paymentRequestID and otherwise cleaned up
discussion of reconciliation.
* Now that we have canHandle I removed some other notes and provided a
forward reference to it.

* Updated formulation based on 10 January discussion

Comprehensive edit to clean up description of the model and how
recommended payment apps fit in:
 https://www.w3.org/2017/01/10-apps-minutes

* Add link to issue 48 per AHB request