Prevent native Error class hi-jacking in FS errors

### Version v16.9.0 ### Platform Linux vagrant-docker 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux ### Subsystem fs ### What steps will reproduce the bug? In the current state of the `promises` section of the native `fs` module, when an error occurs, the native type `Error` is hi-jacked and a `code` property is being added to the error object. This can easily be reproduced with the following code: ```javascript import { promises as FileSystem } from "fs"; try { FileSystem.stat("/a/path/leading/to/nothing"); } catch (error) { console.log(Object.getPrototypeOf(error); // Will display the native class "Error" console.log(Object.getOwnPropertyDescriptors(error); // Will display the added code property that isn't native to Error. } ``` ### How often does it reproduce? Is there a required condition? No required conditions outside of the use of the `fs` native module. ### What is the expected behavior? This isn't a bug per-se but is a bad practice. A custom error of type `FileSystemError` should be thrown instead of hi-jacking the Error class to dynamically add a property to the object. This behavior leads to problematic linting and testing with super-sets such as TypeScript or Eslint. Since `code` is not a native property of `Error` and dynamic property setting is often considered bad practice, it leads to situations where handling those specific issues requires extra effort to circumvent this design. ### What do you see instead? _No response_ ### Additional information Ideally a custom `FileSystemError` should be created such as (Typescript example for types clarity): ```typescript class FileSystemError extends Error { public code: string; // Ideally should be an enum listing all the possible values. } ```