Tidy up the window.postMessage algorithm further

[domenic]

• Makes the origin-checking logic clearer by consolidating the logic
  that determines targetOrigin in one place.
• Since an environment settings object's origin is its responsible
  document's origin, we can just use the former phrase.
• Since the default action concept is not supposed to exist (Spec still talks about "default actions" for events #805), we
  don't need to say there's no default action.
• Save "this Window object" as targetWindow, since it isn't really
  meaningful once we've returned from the method and started running
  steps in parallel.
• Consistently use camelCase variables, since that seems to be the way
  things are heading these days.

[annevk]

then*

[domenic]

Went ahead and did a bunch of consistification/tidying of the other two postMessages. Best to review the output probably.

New commit message proposal:

Tidy up the various postMessage algorithms

For window.postMessage in particular:
* Makes the origin-checking logic clearer by consolidating the logic
  that determines targetOrigin in one place.
* Since an environment settings object's origin is its responsible
  document's origin, we can just use the former phrase.
* Save "this Window object" as targetWindow, since it isn't really
  meaningful once we've returned from the method and started running
  steps in parallel.

In general:

* Since the default action concept is not supposed to exist (#805), we
  don't need to say there's no default action.
* Consistently use camelCase variables, since that seems to be the way
  things are heading these days.
* Use "this Window/MessagePort/BroadcastChannel object" more
  consistently, and specify arguments in the <dfn>.
* Other miscellaneous consistification.

[annevk]

object, when invoked,*

[annevk]

LGTM % modulo nits.