We should distinguish viewerSpace from other XRSpaces

[Manishearth]

Currently session.viewerSpace produces an XRSpace, however while session.viewerSpace says what the space should do, there's no indication on XRSpace itself that it may have such behavior.

Especially once we start more explicitly speccing what the pose of an given space is (an outcome I hope will come out of the discussion in #565 , one which I'm willing to help write spec text for), we'll kinda need a way to differentiate between viewerSpace XRSpaces and other XRSpaces.

There are two ways to do this:

• either we define XRViewerSpace as a new thing. This is similar to what Chromium does internally, though it's not a real interface, just a subclass
• we have a is_viewer_space internal flag on XRSpace, and session.viewerSpace constructs one with that flag set, everything else does not.

I kinda prefer the former since over time that will make it easier to write stuff in the specs for each space.

[NellWaliczek]

So the interesting thing about this issue is that it highlights a really important distinction. What we define at the API/IDL layer is often a stripped down or simplified model of the implementation concepts. Just because we keep the API simple because it's easier to add API surface area later, doesn't mean we can get away with the spec text not having concrete definitions of the different "subtypes".

In other words, the spec text ought to contain a clearly defined "viewer space" type that should not exist in the idl.

[Manishearth]

Sounds good. I wrote this issue before the PR for consolidating most of the reference spaces into a single type happened, so I wanted to match that model, but having an internal type also works. I can make a PR for this once #587 lands

[Manishearth]

This will be fixed by https://github.com/immersive-web/editor-collab/pull/38 once #587 lands

[toji]

Fixed by #621