fix(fslib): fix FileHandle implementations

[mhassan1]

What's the problem this PR addresses?
This PR fixes the following patchFs issues:

• BREAKING CHANGE: promisified fs.write now returns an object
• BREAKING CHANGE: handle.read now returns an object
• BREAKING CHANGE: handle.write now returns an object
• fix handle.truncate and other methods that expect path instead of fd

Resolves #4372.

How did you fix it?

• I fixed the promisified fs.write implementation, similar to fix: Match promisified fs.read call return with original implementation #2128
• I added handle.read and handle.write implementations that use promisified fs.read and fs.write
• I added a non-enumerable property to FileHandle for storing the file handle path so it can be passed to methods like truncatePromise, which expect path instead of fd
• I extended FILEHANDLE_IMPLEMENTATIONS to specify whether a method expects fd (e.g. readFilePromise) or path (e.g. truncatePromise)

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]

There is already a PR fixing the FileHandle implementation #3889.

I fixed the promisified fs.write implementation

Could you extract that to a separate PR?

I added a non-enumerable property to FileHandle for storing the file handle path so it can be passed to methods like truncatePromise, which expect path instead of fd

We can't use truncate we have to implement ftruncate and use that.

I extended FILEHANDLE_IMPLEMENTATIONS to specify whether a method expects fd (e.g. readFilePromise) or path (e.g. truncatePromise)

We can't just call the path version of the fs functions, we have to use the file descriptor versions.

[mhassan1]

Thanks for the feedback. I didn't realize there was an outstanding PR for most of this. I am declining this PR.