feat(ext/ffi): Add static method variants to Deno.UnsafePointerView

[aapoalas]

Add static method variants to Deno.UnsafePointerView for usage with pointer BigInts. Since Deno.UnsafePointer is no longer a thing that exists and BigInt values are returned directly, it seems like it might be helpful to offer static variants for the more direct return types that Deno FFI does not directly support.

This PR depends on #15143

Examples:

const pointer = dylib.symbols.get_pointer();
const string = Deno.UnsafePointerView.getCString(pointer); // Function returning a cstring is common enough
const buffer = Deno.UnsafePointerView.getArrayBuffer(pointer); // Getting a zero-copy AB from a pointer is useful, especially if mutations need to be done.
const copyBuffer = new Uint8Array(32);
Deno.UnsafePointerView.copyInto(pointer, copyBuffer); // Less useful perhaps, but if a copy of a buffer is needed, it can be done.

These static methods do not have pointer offsets offered, as those seem like a special case and if offsets are needed, then creating a Deno.UnsafePointerView seems apt to actually "view into" the pointer.

Additionally, I did not create static methods for the numeric return values as it seems unlikely that a function would return just a *const u8 or similar. Again, if viewing into a pointer that contains a struct which contains numeric values is needed, then creating a Deno.UnsafePointerView seems apt.

[aapoalas]

Should I add offset parameters to these APIs? I think they'd be useless but it'd then align with the existing APIs.

Reasons for uselessness:

1. getCString: I would presume any char pointer with a prefixed header would be quite uncommon. It could be handled using getArrayBuffer for the header + subarray to the end of the header, to UnsafePointer.of() + getCString.
2. getArrayBuffer / copyInto: Any offset can be handled with a subarray.