Clarify behavior when the receiving page attempts to navigate itself

[tidoust]

Issue initially raised in #449 (comment)

In 6.6.1, the Presentation API spec says that, in receiving contexts, "The top-level browsing context MUST NOT be allowed to navigate itself", but it does not explain what is to happen if it attempts to do so.

Two main possibilities:

1. Abort with a SecurityError.
2. Close the receiving browsing context.

We should probably be doing 1. (see #449 (comment)): it is consistent with the navigate algorithm in HTML when the context is not "allowed to navigate" and is developer-friendly since it allows them to debug the situation. Problem is it is harder to implement and it does not match what Chrome is currently doing. Second possibility matches how Chrome currently behaves, is easier to implement, but makes it harder for developers to debug and is not consistent with the usual navigation algorithm.

[mfoltzgoogle]

Spec comments:

• Our spec should reference the allowed to navigate algorithm in HTML because we already referencing the sandboxed top-level navigation browsing context flag that is used by it.
• However presentation receivers also block self-navigation, which has no equivalent in HTML. The spec should be clear this is an additional condition on top of HTML allowed to navigate.

Implementation comments:

• Because there is no flag in HTML for the self-navigation case, aborting navigation or throwing is more challenging.
• I don't see a strong use case for receiving user agents offering to open in a new window, but no reason to block it.
• Therefore, in the spec I recommend that the behavior for blocked navigation SHOULD be consistent with HTML.

I can put together a PR along these lines for review.

In the long run, this requirement may be too restrictive. For example, in Chrome PWA's are allowed to self-navigate within their URL scope without showing an address bar. We should think about the tradeoffs here.

[mfoltzgoogle]

Regarding Chrome's behavior specifically, filed https://crbug.com/949350 to improve the behavior here, but it's tricky.

[mfoltzgoogle]

Closed by PR #461.