Document our design principles / rules of thumb

[foolip]

In https://github.com/w3c/webdriver-bidi/issues/46#issuecomment-739803667 I spelled out a principle about the ability to implement WebDriver BiDi both as part of a driver binary like ChromeDriver, or as part of the browser directly, and avoiding assumptions that only make sense in one scenario. @jgraham agreed:

I don't think that there's a requirement that the connection has multiple hops (I don't expect the gecko implementation to have multiple hops in the default case). There may also be middleware that adds additional hops to the connection.

It would be good to write down some things like this which we've converged on, to be able to point to. A few others that come to mind, which I don't know if others agree with:

• err on the side of matching existing debugging/inspector protocols where the benefit of being different is not very clear
• forward compatibility: "a design characteristic that allows a system to accept input intended for a later version of itself."
• provide the building blocks needed to do something first, and higher-level conveniences only if they can be expressed in terms of those building blocks, and if the convenience is almost universally needed.

[foolip]

@sadym-chromium points via in https://github.com/w3c/webdriver-bidi/issues/82 that maybe we should also have a rule about an Id suffix for identifiers.