[JS] Int and Float fixes

[trxcllnt]

• Fix IntVector.from() and FloatVector.from() type signatures
  • Allow them to accept Iterable<number> as data if called on the more specific subclasses
  • Convert float32/float64 to uint16s when creating a Float16Vector
• Make Float16Vector#toArray() return a subarray slice of the Uint16Array data
  • Adds Float16Vector#toFloat32Array() and Float16Vector#toFloat64Array() to enable the up-casting copy behavior
• Add zero-copy Int64Vector#toBigInt64Array() and Uint64Vector#toBigUint64Array() for envs where available
• Use BigInt and related arrays to print int64/uint64s inside the BigNumNMixin
• Support BigInt in comparator and Int64Vector#indexOf() and Uint64Vector#indexOf() signatures

[TheNeuralBit]

I don't really follow this syntax, with the this argument, could you clarify what's going on here?

I assume it somehow makes it so that both FloatVector.from(new Float32Array()) and Float32Vector.from([1,2,3]) yield a Float32Vector but I don't really understand how.

[trxcllnt]

@TheNeuralBit yep! In plain English it'd be something like, "If this == Float16Vector constructor, accept data as either Uint16Array or any Iterable<number>, and always return an instance of Float16Vector." It's there to ensure that Float16Vector.from([1, 2, 3]) instanceof Float16Vector is always true at compile and run-times.

TypeScript doesn't grant much latitude when it comes to subclasses overriding inherited static functions, so we have to hoist the narrower type definitions up to the base. You can also see here how I figured out how to check this case in the unit tests.