Internal method linking

[bakkot]

Followup to #666. Fixes #116.

Corresponding ecma262 PR at tc39/ecma262#3912.

This is a breaking change because it now expects type="internal method" clauses, which are the clauses that define the actual implementations of the various methods on the various kinds of object, to have a corresponding definition in the tables of essential internal methods.

Claude wrote this from the following prompt, wherein I basically told it to copy #666.

prompt

This is ecmarkup, the tool used to build the JS spec.

In commit 2720d8e, we added support for linking abstract/concrete methods within the spec (these have nothing to do with JS methods). These are things like HasBinding on Environment Records, which has multiple implementations (for a block scope vs a with scope, e.g.). Read that commit for context.

We want to do something similar for so-called "internal methods". These currently look like

    <emu-clause id="sec-ordinary-object-internal-methods-and-internal-slots-getprototypeof" type="internal method">
      <h1>[[GetPrototypeOf]] ( ): a normal completion containing either an Object or *null*</h1>
      <dl class="header">
        <dt>for</dt>
        <dd>an ordinary object _obj_</dd>
      </dl>
      <emu-alg>
        1. Return OrdinaryGetPrototypeOf(_obj_).
      </emu-alg>

Note that they already have a type and structured header, so there is less to do than there was for concrete methods (which did not). Also note that these always have the [[ brackets; they are invoked as e.g. _foo_.[[GetPrototypeOf]](). Otherwise, we want to take a very similar approach as in the above commit, including the new element for generating the list of implementations.

plus a couple minor followups.

[nicolo-ribaudo]

One minor suggestion but otherwise it looks good 👍