Preparing for Immutable / Limited ArrayBuffer

* https://github.com/tc39/proposal-immutable-arraybuffer
* https://github.com/tc39/proposal-limited-arraybuffer

The Immutable ArrayBuffer and Limited ArrayBuffer proposals are advancing in TC-39. We have some time before we need to worry about them but we do need to prepare.

An Immutable ArrayBuffer is exactly what it says on the tin. Once allocated and marked immutable, the memory is expected to remain stable and unmodified -- even at the host runtime level. This obviously means that our current `ArrayBuffer <-> kj::Array` type mapping will need to be updated to account for the possible immutability of the underlying backing store.

To support this, I am proposing:

* We update `jsg::BufferSource` to add a new "isImmutable()" property, and when the `jsg::BufferSource` is wrapping an immutable backing store, the `kj::ArrayPtr` it produces to provide access to the underlying data would be a `kj::ArrayPtr`. Modifications to the underlying data would be blocked.
* We add a new `Immutable ArrayBuffer <-> const kj::Array` type mapping and make it so that the current `ArrayBuffer <-> kj::Array` type mapping receives an immutable ArrayBuffer an error is thrown.

The Limited ArrayBuffer proposal provides a way of generating a read-only *View* of an otherwise mutable ArrayBuffer. When given such a view, it MUST be treated equivalently as an Immutable ArrayBuffer even if the underlying backing store is mutable. We *ought* to be able to handle this transparently in the type mapping modifications mentioned above.

There is no rush on this, however, and the changes required are relatively straightforward so work on this should proceed only when v8 implements the feature and ships it unflagged.