Reduce b4a usage and prefer the native Buffer methods

[SukkaW]

The PR reduces some b4a usages:

• b4a.alloc
  • b4a.alloc is just an alias of Buffer.alloc, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L9-#L11
• b4a.concat
  • b4a.concat is just an alias of Buffer.concat, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L29-L31
• b4a.from
  • b4a.from is just an alias of Buffer.from, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L45-L47
• b4a.byteLength
  • b4a.byteLength is just an alias of Buffer.byteLength, see https://github.com/holepunchto/b4a/blob/5a6b328df1817977351208e1991b1fdfb4bfa529/index.js#L21

By replacing those b4a usage with Node.js built-in Buffer, the PR improves performance (as those alias methods would create extra stacks), and makes it easier to transition to the Uint8Array in future PRs.

The unit tests still pass after the changes.

[mafintosh]

The b4a is there to make it run in the browser, overhead is negligible, and prop even optimised out by v8

[SukkaW]

The b4a is there to make it run in the browser, overhead is negligible, and prop even optimised out by v8

@mafintosh Sure, that makes sense.

My original plan was to entirely transition from Buffer to Uint8Array as a preliminary step towards resolving the issue #157. This would begin with unifying Buffer usage followed by subsequent PRs focusing on migrating away from Buffer.

Maybe I should open a PR to migrate to Uint8Array directly, what do you think?