[Feature Policy] Establish guidance about policy-controlled features for new XR features

[ddorwin]

The solution for Feature Policy for the core ("VR Complete") WebXR Device API spec (see #308) is fairly simple and defers a lot of the complexity to the future. While we don't need to solve the reset now, we will fairly soon as incubations and/or additional modules mature. As noted at the end of #729 (comment), we can't retroactively give developers control later, so it's important that new features/APIs/extensions of WebXR do the right thing before anyone ships them.

Thus, as much as possible, we should try to formalize the idea that new features / extensions of WebXR must carefully consider whether they also depend on additional policy-controlled feature(s) and provide guidance on choosing/defining a new policy-controlled feature (or reusing an existing one) in a way that is consistent with the overall design/intent.

Relevant discussions that may feed into this guidance include #308, #729, #763, and #765.

[probot-label]

This issue is fixed by PR #842