feat(immutable-arraybuffer): transferToImmutable ponyfill and shim

[erights]

Closes: #XXXX
Refs: #1538 #1331 #2309 #2311

Description

Introduces the @endo/immutable-arraybuffer package, the ponyfill exports of @endo/immutable-arraybuffer, and the shim obtained by importing @endo/immutable-arraybuffer/shim.js.

Alternative to #2309 as suggested by @phoddie at #2309 (comment)

We plan to fix #1331 in a stack of PRs starting with this one

• This PR implements a ponyfill and shim for an upcoming Immutable ArrayBuffer proposal, along the lines suggested by @phoddie at feat(ses): ImmutableArrayBuffer #2309 (comment) + the suggestions on an earlier state of feat(ses): ArrayBuffer.p.transferToImmutable #2311 . This is a pure JavaScript ponyfill/shim, leaving it to feat(ses): ArrayBuffer.p.transferToImmutable #2311 to bring it into Hardened JavaScript.
• feat(ses): ArrayBuffer.p.transferToImmutable #2311 imports the feat(immutable-arraybuffer): transferToImmutable ponyfill and shim #2399 shim, treating the new objects it introduces as if they are new primordials, to be permitted and hardened.
• feat(pass-style,marshal): ByteArray, a new binary Passable type #1538 uses the Hardened JavaScript Immutable ArrayBuffers to define a new Passable type, ByteArray, corresponding to the OCapN ByteArray.
• Some future PR extending the various marshal formats to encode and decode the ByteArray objects.

See the README.md in this PR for more.

Security Considerations

Better support for immutability generally helps security. The imperfections of the shim are a leaky abstraction in all the ways explained in the Caveats section of the README.md. For example, objects that are purely artifacts of the emulation, like the immutableArrayBufferPrototype, are easily discoverable, revealing the emulation's mechanisms.

As a pure JavaScript polyfill/shim, this @endo/immutable-arraybuffer package does not harden the objects it exposes. Thus, by itself it does not provide much security -- like the initial state of JavaScript does not by itself provide much security. Rather, both provide securability, depending on Hardened JavaScript to harden early as needed to provide the security. See #2311

Once hardened early, the abstraction will still be leaky as above, but the immutability of the buffer contents are robustly enforced.

Scaling Considerations

This ponyfill/shim is a zero-copy implementation, meaning that it does no more buffer copying than expected of a native implementation.

Compatibility and Documentation Considerations

This ponyfill/shim implements zero-copy by relying on the platform to provide one of two primitives: structuredClone or ArrayBuffer.prototype.transfer. Neither exist on Node <= 16. Without either, this ponyfill/shim will fail to initialize.

This PR sets the stage for writing an Immutable ArrayBuffer proposal, proposing it to tc39, and including it in our own documentation.

Testing Considerations

Ideally, we should identify the subset of test262 ArrayBuffer tests that should be applicable to immutable ArrayBuffers, and duplicate them for that purpose.

Upgrade Considerations

Nothing breaking.

[erights]

OCapN meeting coming up on Tuesday. So if there's no problem with this, I'd like to make progress before then. Ping ;)

[gibson042]

The code looks reasonable, but I feel pretty strongly that we should not have a polyfill at all... liveslots will need to use a new endo to take advantage of this anyway, and it IMO should explicitly propagate transferBufferToImmutable and isBufferImmutable as globals into all descendant compartments rather than manipulating a built-in prototype and creating compatibility concerns.