fix: Match promisified fs.read call return with original implementation

[Mike-Dax]

What's the problem this PR addresses?

Fixes #2127
Fixes serialport/node-serialport#2158

...

How did you fix it?

Node stores whether or not the promisified version should have a different return shape in a symbol (internalUtil.customPromisifyArgs) that's private, we can't access that.

https://github.com/nodejs/node/blob/dc79f3f37caf6f25b8efee4623bec31e2c20f595/lib/fs.js#L559-L560

However the util.promisify function caches implementations in a cache key that's a global symbol (available at util.promisify.custom). We can pre-populate that cache with a version of the function that works.

https://github.com/nodejs/node/blob/ba684805b6c0eded76e5cd89ee00328ac7a59365/lib/internal/util.js#L274,L281

This PR implements a pre-cached function that returns an object of the same shape as util.promisify(fs.read) would on a standard node system
...

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[merceyz]

Could you add a test to make sure we don't regress on this in the future?

[arcanis]

For that, a unit test in patchedFs.test.ts will do the trick

[arcanis]

Shouldn't we do the same for write / readv / writev?

[Mike-Dax]

Those other three aren't patched, so this problem doesn't occur.

If we wanted to patch those methods, then yeah we should do the promisify patching.

[Mike-Dax]

I've added a test to validate the returned object shape. I tried to write a test that ran the unpatched fs.read then patched fs, and compared the two, but I couldn't seem to get access to the unpatched fs.read.