All the following texts were translated from Chinese by GPT-4.
If any wording comes across as offensive, please forgive me, it was not my intention.
Thanks to @bengl early work, this PR evolved from his efforts (#46905).

How to use

Currently, FFI does not support all the platforms that Node.js supports.
To avoid compilation failures on unsupported platforms and to prevent confusion for developers,
I have added a compile-time flag, which is disabled by default.
Here is an example of the configure commands:

Or you are on the Windows platform.

This is an experimental feature.
You must run Node with the --experimental-ffi flag to use it.
Additionally, it is a security-sensitive feature,
so you also need to use the --allow-ffi flag.
By default, all permissions are enabled unless the permission model
is manually activated by using the flag --permission or any --allow-* flag.
Here is a command-line example:

This is a test code that can run on the Windows platform.

About the "libffi/fixed" and automake dependency

The core of this feature relies on calling the libffi library.
Referencing libffi is challenging because it heavily depends on automake and has poor support for MSVC.
To successfully integrate this library, I made some adjustments.
First, I streamlined the library's files by removing parts we don't currently need.
These can be added back in as needed.
Next, I created a separate fixed folder where I wrote files:
ffi.h, ffi.c, ffiasm.S, fficonfig.h and ffitarget.h.
These files use #if macros to handle most of the work that would normally be done by automake.
Upgrading libffi in the future is both necessary and entirely feasible.
I only added files without modifying any of libffi's existing files.
When updating to a newer version of libffi,
you simply need to replace the corresponding files.

Support Platform

Here is the system and CPU support status:

1. Blank spaces in the table indicate the absence of such combinations.
   Windows does not support the fifth type of CPU,
   and Mac only supports x64 and ARM64.
2. Windows x86 is the most unique platform because it has numerous calling conventions,
   which are an important part of a function's signature.
   However, our JS API does not have a field to specify the calling convention.
   Fortunately, this platform is no longer actively supported by Node.js,
   so we can reasonably abandon it.
3. The hybrid architecture (Windows ARM-EC) is a crazy idea,
   and I'm not sure whether this technology is widely used.
   Undoubtedly, it presents significant challenges for FFI.
   Currently, it is not supported and likely won't be in the future either.
4. Support for other architectures and systems will be addressed in future PRs.

About ffi double

For @atgreen:
It seems that a double type field is missing in ffi_raw.
Was this intentionally designed?
Although this issue can be resolved by forcibly casting the pointer type,
I didn't do so because I suspect there might be some traps I'm unaware of waiting for me.

About compatibility with Deno.js

For @aapoalas:
A portion of the content remains unimplemented, divided into three parts:

• the UnsafeCallback.threadSafe method
• the nonblocking option,
• and all methods of UnsafePointerView except static getArrayBuffer.

threadSafe and nonblocking

the threadSafe method should not be able to exist independently of nonblocking.
The most complex callback scenarios I can think of
are the Win32 window procedure callback and APC invocation.
The former involves registering a callback method in RegisterWndClass,
and later, during the message loop,
the thread processes the window procedure by calling DispatchMessage.
The latter involves registering a callback method in ReadFileEx,
and subsequently, the APC callback is entered internally within the SleepEx method.
In any case, the prerequisite for the current thread to enter a callback function
is that the thread must call a certain method,
and this method will internally locate the callback function pointer recorded somewhere,
and then enter the callback function.
A thread cannot arbitrarily enter a callback function at any location;
perhaps only Linux's signal method has such magical capabilities.
In summary, threadSafe seems to apply only to certain specific scenarios.
For example, an independent thread outside of the Node.js event loop executes some kind of loop,
and at a certain point in the loop,
it sends a message to the Node.js main thread.
Wouldn't such a requirement be more suitable for implementation
in a third-party library rather than in the core code of Node.js or Deno.js?

UnsafePointerView

The functionality of UnsafePointerView is to read arbitrary memory addresses in JavaScript.
However, after creating an ArrayBuffer via a pointer,
most of the features of this class become redundant,
as they can be replaced by TypedArray, DataView, or Buffer (Node.js only).
Therefore, UnsafePointerView seems to merely act as a wrapper?

Open issues

I can't wait to share this module with everyone!
The following tasks have not been completed yet,
but perhaps they can be ignored in this PR and completed in future PRs:

1. Documentation for the ffi module (nightly users can refer to Deno.js's documentation).
2. Support only for Windows, Linux, Mac platforms, and certain CPU architectures.
3. Auto-update scripts for libffi.
4. Unit test code and benchmark test code
5. The double type is not supported.
6. Not fully compatible with Deno.js.
7. Other details I haven't thought of yet.