Add PresentationReceiver and navigator.presentation.receiver to access it.

[mounirlamouri]

This is moving around some spec definitions to apply on
PresentationReceiver instead of Presentation, the examples have been
changed and navigator.presentation.receiver has been defined.

Fixes #91.

[anssiko]

See #91 (comment) re the conformance section.

[mounirlamouri]

I think my wording is fine. If a browsing context isn't a presenting browsing context, it MUST return null, and return an instance of PresentationReceiver otherwise. Clearly, that means that a controlling UA MUST implement PresentationReceiver.

What do you think should be added?

[anssiko]

@tidoust Please review and see if this matches your expectations re conformance requirements.

[tidoust]

@mounirlamouri Could you clarify why you want a controlling UA to implement PresentationReceiver? Or is it a typo in your comment?

I do not know in which order #91 and #93 should be done. I think that the pull request is fine provided that we keep #93 open. Once "presenting UA" and "controlling UA" are defined as conformance classes, sentences such as: "The receiver MUST return null if the current browsing context is not a presenting browsing context and return a PresentationReceiver instance otherwise" may need to be revisited to clarify what each type of UA needs to implement precisely.

For instance, here, I am not clear what "typeof PresentationRequest" will return in a presenting-only UA. If defined, that would mean that the UA needs to implement the Constructor too and thus some "fake" logic. How would a Web app know that it's useless to offer the user with a "present" button in that case?

[mounirlamouri]

Indeed, that was a typo, I meant that a presenting UA MUST implement PresentationReceiver.

A controlling MAY implement PresentationReceiver. I guess the only question is whether a controlling UA should have the interface in its global scope or not. I don't think that's a major issue and it could probably be defined in #93.

[markafoltz]

Is "receiver" defined yet in the document? Would restate as:

Presenting context: monitor available session(s) and say hello.

[mounirlamouri]

Done.

[markafoltz]

Looks good - with some editorial suggestions.

I agree with @tidoust that we should revisit the behavior of this API once the document is restructured around conformance classes, and nail down what everything does in each.

[mounirlamouri]

Comments applied, merging. Thanks for the review!