[Feature] Implement Buffer Class

[jtenner]

This pull request aims to implement the node Buffer class to the best of my ability. I know we were flip-flopping on this a while ago, and instead of just opening an issue about Buffer support (and being ungreatful,) I thought I should pick up and learn how it works so I can personally do something about it.

Notes:

• We can only implement one of the constructors, I chose new Buffer(size: i32) to be consistent with AS

Checklist:

• new Buffer(size); (deprecated in node, but required for new Uint8Array constructor)
• Class Method: Buffer.alloc(size[, fill[, encoding]])
• Class Method: Buffer.allocUnsafe(size)
• Class Method: Buffer.allocUnsafeSlow(size)
• Class Method: Buffer.byteLength(string[, encoding])
• Class Method: Buffer.compare(buf1, buf2)
• Class Method: Buffer.concat(list[, totalLength])
• Class Method: Buffer.from(ArrayBufferView)
• Class Method: Buffer.from(arrayBuffer[, byteOffset[, length]])
  • This method should probably skip byteOffset and length properties
• Class Method: Buffer.from(string[, encoding])
  • This method could use the encoding parameter Buffer.from("str", "encoding")
• Class Method: Buffer.isBuffer(obj)
• Class Method: Buffer.isEncoding(encoding)
• Class Property: Buffer.poolSize
• buf[index]
• buf.buffer
• buf.byteOffset
• buf.compare(target[, targetStart[, targetEnd[, sourceStart[, sourceEnd]]]])
• buf.copy(target[, targetStart[, sourceStart[, sourceEnd]]])
• buf.entries()
• buf.equals(otherBuffer)
• buf.fill(value[, offset[, end]][, encoding])
• buf.includes(value[, byteOffset][, encoding])
• buf.indexOf(value[, byteOffset][, encoding])
• buf.keys()
• buf.lastIndexOf(value[, byteOffset][, encoding])
• buf.length
• buf.readBigInt64BE([offset])
• buf.readBigInt64LE([offset])
• buf.readBigUInt64BE([offset])
• buf.readBigUInt64LE([offset])
• buf.readDoubleBE([offset])
• buf.readDoubleLE([offset])
• buf.readFloatBE([offset])
• buf.readFloatLE([offset])
• buf.readInt8([offset])
• buf.readInt16BE([offset])
• buf.readInt16LE([offset])
• buf.readInt32BE([offset])
• buf.readInt32LE([offset])
• buf.readIntBE(offset, byteLength)
• buf.readIntLE(offset, byteLength)
• buf.readUInt8([offset])
• buf.readUInt16BE([offset])
• buf.readUInt16LE([offset])
• buf.readUInt32BE([offset])
• buf.readUInt32LE([offset])
• buf.readUIntBE(offset, byteLength)
• buf.readUIntLE(offset, byteLength)
• buf.subarray([start[, end]])
• buf.slice([start[, end]])
• buf.swap16()
• buf.swap32()
• buf.swap64()
• buf.toJSON()
• buf.toString([encoding[, start[, end]]])
• buf.values()
• buf.write(string[, offset[, length]][, encoding])
• buf.writeBigInt64BE(value[, offset])
• buf.writeBigInt64LE(value[, offset])
• buf.writeBigUInt64BE(value[, offset])
• buf.writeBigUInt64LE(value[, offset])
• buf.writeDoubleBE(value[, offset])
• buf.writeDoubleLE(value[, offset])
• buf.writeFloatBE(value[, offset])
• buf.writeFloatLE(value[, offset])
• buf.writeInt8(value[, offset])
• buf.writeInt16BE(value[, offset])
• buf.writeInt16LE(value[, offset])
• buf.writeInt32BE(value[, offset])
• buf.writeInt32LE(value[, offset])
• buf.writeIntBE(value, offset, byteLength)
• buf.writeIntLE(value, offset, byteLength)
• buf.writeUInt8(value[, offset])
• buf.writeUInt16BE(value[, offset])
• buf.writeUInt16LE(value[, offset])
• buf.writeUInt32BE(value[, offset])
• buf.writeUInt32LE(value[, offset])
• buf.writeUIntBE(value, offset, byteLength)
• buf.writeUIntLE(value, offset, byteLength)

[dcodeIO]

I'm generally in favor of adding a Buffer class (and other node APIs), just not sure if the node API implementations should live in its own module, like "@assemblyscript/std-node". If it doesn't, we might run into situations where sometimes the normal JS API is used in a PR, and sometimes the node API is used, so it will be hard to split that again at a later point. Also, having it directly in stdlib increases initial parse times because it'd add additional classes to the global scope (so it must parse to know the globals), like Buffer or an implementation of process, which would be unnecessary if someone doesn't plan to use it.

Nonetheless, due to its expected importance my suggestion is to make it an official AS repo so everyone can contribute and we can maintain. Wdyt? :)

[jtenner]

If you make the repo, I'll close this pull request in favor of a pull request to the repo.

Count me in.

[MaxGraey]

I also think assemblyscript/node_std repo is good idea for that

[jtenner]

Closed in favor of standardizing the node apis in its own repo. Just waiting on @dcodeIO to make the repo.