Updates PresentationRequest to take multiple URLs

[markafoltz]

This PR addresses Issue #311 (Add presentation request URL fallback mechanism). It modifies the PresentationRequest constructor to take an array of URLs each of which will be considered in order when starting or connecting to a presentation.

This necessitated several changes, including:

• Updating example code
• Updating interfaces, including adding a url property to PresentationConnection so the caller knows what is being presented
• Updating the set of availability objects to have a list of URLs per object
• Updating the list (set?) of available presentation displays to keep track of which displays are compatible with which URLs so the start algorithm can choose the appropriate URL for the chosen display
• Various other algorithm and wording updates

@mounirlamouri @tidoust @sicking @schien Please take a look.

[tidoust]

Examples should all use example.com, example.net, example.org or subdomains:
http://www.w3.org/2001/06/manual/#Examples

I suggest to switch to: http://example.net/alternate.html

[markafoltz]

Done

[tidoust]

See a couple of comments inline. The only substantive comment is that I would have expected the PresentationRequest constructor that only takes one URL to remain in the spec.

Changes to algorithms look all good to me otherwise!

[mounirlamouri]

Do we want to allow (DOMString[] or DOMString) for simplicity and backward compatibility?

[tidoust]

That works for me. That seems to improve readability as well!

[anssiko]

I would suggest we keep the @mfoltzgoogle's initial form with two [Constructor]s. That allows us to address both the singular url as well as its plural form urls in the algorithm that follows.

[markafoltz]

Sorry for the delayed reply, was on vacation last week. The dual constructor form should be backwards compatible, although do I assume an implementation will be able to overload a single-argument constructor in this way? For example code generated from the .idl would need to examine the argument type to dispatch to an appropriate function.

I'm not opposed to using a union type instead if there's a preference.

[anssiko]

Thanks @mfoltzgoogle for crafting this substantial PR.

All - this PR has been open for 2 weeks, so my expectation is everyone has had time to review it. The comments received have been addressed by the editor sans @mounirlamouri's #316 (comment) that suggested using a single [Constructor] with a union type (DOMString[] or DOMString) as its argument over the use of multiple [Constructor] extended attributes [Constructor(DOMString url), Constructor(DOMString[] urls)].

@mounirlamouri could you clarify the compatibility issue?

Meanwhile, I'll merge merge this PR, with a condition that we may switch to the union type if the compatibility impact is deemed significant.