applyConstraint with depthMapUnit should only be rejected if mandatory

[stefhak]

May be moot because of #100 - but otherwise I think the promise should only be rejected based on this if depthMapUnit is mandatory.

[jan-ivar]

Assuming we do what's suggested in #100 (rename to something like depthPrecision and standardize values on an API unit), then why couldn't users change depthPrecision with applyConstraints? Constraints let tabs negotiate for a shared resource, and I see no reason UAs couldn't handle this.

Other issues:

• Typo: We can't have unit in both MediaTrackConstraintSet and MediaTrackConstraints, since the latter is derived from the former.
• Use DOMString instead of WebIDL enum in constraints (see facingMode).
• To support mandatory constraints (e.g. applyConstraints({ depthPrecision: { exact: "m" } }), the type in MediaTrackConstraintSet needs to be ConstrainDOMString (again like facingMode).

[jan-ivar]

Also:

• Default values must be avoided in MediaTrackConstraintSet, as a rule. *

*) because default values get implicitly inserted by webidl binding code to provide implementations with invariants, which is great, except MediaTrackConstraintSet is reused in advanced where the semantics of absence differs from providing a (default) value.

[anssiko]

This issue fixed itself:

• applyConstraints() special casing was removed in 13132ae as agreed in Fix #114: Add depthNear and depthFar constrainable properties #118.
• depthMapUnit/DepthPrecisionEnum was removed in 461fd20 as agreed in Setting unit in constraints #100.