Multiple User Script Worlds proposal polish

[dotproto]

This PR introduces 3 clarifications to the Allow multiple user script worlds proposal.

Clarify behavior of omitting RegisteredUserScript.worldId

Currently the comment on the RegisteredUserScript.worldId property states:

If specified, specifies a specific user script world ID to execute in. Only valid if world is omitted or is USER_SCRIPT. If omitted, the script will execute in the default user script world.

This phrasing is ambiguous. The "if omitted, …" that begins the last sentence could refer to either the world property or the worldId property. This PR addresses the ambiguity by rewording the start of this sentence to, "if worldId is omitted, …"

Add type definitions for methods on RegisteredUserScript

Currently the proposal states

Note that the signatures of the related functions, including configureWorld(), register(), and others are left unchanged.

This is inaccurate. The original User Scripts API proposal does not define an interface used by the configureWorld() method in the Types section or declare the configureWorld() method in the Methods section. Instead, the definition of configureWorld() appears in a sub-section of Requirements and uses an object literal to define it's parameter.

browser.userScripts.configureWorld({
  csp?: string,
  messaging?: boolean,
})

The methods introduced in the Multiple User Script Worlds proposal user a different declaration pattern than the previous proposal.

In order to more clearly communicate what has and has not changed in the Multiple User Script Worlds proposal, this PR adds type definitions for the methods on the userScripts namespace that match the pattern used by this proposal. I also clarifies that the object literal used in the original definition of configureWorld() is analogous to the WorldProperties object that is first defined in the Multiple User Script Worlds proposal.

Clarify how userScripts methods are affected

After the diff of "Relevant methods and types", the following paragraph appears in the current text.

Note that the signatures of the related functions, including configureWorld(), register(), and others are left unchanged.

While it is accurate to say that the function signature are unchanged in a static language, it's applicable in a dynamic language like JavaScript that rely heavily on duck typing. Generally speaking, I would say that the type signature of a JavaScript function changes if the shape of the object it accepts changes. While the names of the types are the same (except for configureWorld() as previously described), a different set of ducks would pass these checks.

In order to be more clear about what did and did not change, this PR revises the line to be more explicit about how method signatures are affected by this proposal.

Note that save for the introduction of worldId on these interfaces, the signatures of the related functions - configureWorld(), register(), and others – are left unchanged.