This supersedes #55 and #52.

We need to flesh out how protocols are represented as object literals. This is used in two places, and needs to be consistent between the two:

• We have a Protocol constructor that takes an object literal and creates a new protocol.
• Protocol.describe() performs the inverse: it takes a protocol and returns an object literal
• This means that while protocols are immutable, protocols can use Protocol.describe() to build new protocols from existing protocols.
• The object representation should be able to represent a superset of what the declarative syntax can represent, though not necessarily a strict superset.

Our current thinking has been something with a general shape like this:

interface ProtocolDescription {
	name?: string,
	implements?: Protocol[],
	members: Record<PropertyKey, {
		required: boolean,
		key?: Symbol,
		value?: any,
		descriptor?: PropertyDescriptor,
		implements?: Protocol[]
	}>
}

or

interface ProtocolDescription {
	name?: string,
	implements?: Protocol[],
	members: Record<PropertyKey, PropertyDescriptor & {
		required: boolean,
		key?: Symbol,
		implements?: Protocol[]
	}>
}

TBD: What are members keys?

• For literal strings, it seems reasonable they would be the string itself.
• For external symbols, it seems reasonable they would be the symbol itself
• But for internal members, are they the string name or the symbol itself? It seems more consistent with the declarative syntax if they are the name, and then Protocol.describe() could return the symbol itself as another property. This also provides a natural data structure for the aliasing syntax we were discussing in Inheritance of symbols from parent to child #23. It does rule out having string members and regular members with the same name (Are "foo" and foo distinct members? #59), but that's probably fine.