Standardize relationship between concept-objects and interface-objects

[inexorabletash]

The relationship between e.g. cursor and IDBCursor is not described consistently. Modern specs (e.g. fetch) formally define the relationship as a script-object IDBCursor having an associated concept-object. This spec just says things like cursor implements IDBCursor, and method definitions implicitly have a "this cursor..." in scope.

The most extreme case of this is detailed in #3 (where object store and IDBObjectStore don't have a 1:1 mapping).

[inexorabletash]

I'm going to drop this from "v2" since the current state of the spec is definitely not worse than "v1" and also not demonstrably worse than many of the specs out there.

[inexorabletash]

Consistent linking text, that should be reviewed/revised:

• "The IDBDatabase interface represents a connection to a database."
• "The IDBObjectStore interface represents an object store handle."
• "The IDBIndex interface represents an index handle."
• "The IDBKeyRange interface represents a key range."

Less consistent links, that should be reviewed/revised:

• "Cursor objects implement the IDBCursor interface. There is only ever one IDBCursor instance representing a given cursor. "
• "A cursor that has its key only flag set to false implements the IDBCursorWithValue interface as well."
• "transaction objects implement the following interface:"
• "Methods on IDBDatabase that return a open request use an extended interface..."

Missing explicit links:

• request and IDBRequest

[inexorabletash]

DOM uses this "known as" pattern:

An Event object is simply named an event.
Document nodes are simply known as documents.
Objects implementing the AbstractRange interface are known as ranges.

... and then goes on to define properties on the concept objects.