ffi: add new methods and error codes

[ShogunPanda]

• Added null support in DynamicLibrary loading on non-Windows (dlopen(NULL) semantics), plus docs clarifying null is not supported on Windows.
• Added a new FFI benchmark benchmark/ffi/getpid.js using ffi.dlopen(null, ...) + uv_os_getpid. Thanks to @bengl for Foreign Function Interface (FFI) implementation #46905
• Documented new FFI error codes in doc/api/errors.md as asked from @jasnell in lib,src,test,doc: add node:ffi module #62072 (comment)
• Code documented behavior of why JS callback may abort the process. This address what requested by @jasnell in lib,src,test,doc: add node:ffi module #62072 (comment).

As promised to @justjake, also the following followups requested in #62072 (comment):

• Added ffi.exportArrayBuffer(...) and ffi.exportArrayBufferView(...).
• Added raw pointer helper ffi.getRawPointer(source) (Buffer | ArrayBuffer | ArrayBufferView), with strong “unsafe/dangerous” docs and tests.
• Moved byte-export copying to native code (exportBytes) to avoid extra JS Buffer wrapper allocations.

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/gyp
• @nodejs/performance

[justjake]

Great! Thank you. It looks like I won't need my own unsafe-pointer once node:ffi gets stabilized 🎉 😄

[codecov]

Codecov Report

❌ Patch coverage is 57.20165% with 104 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.59%. Comparing base (d7ab027) to head (1fee1dd).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
src/ffi/data.cc	41.17%	45 Missing and 15 partials ⚠️
src/node_ffi.cc	46.80%	24 Missing and 1 partial ⚠️
src/ffi/types.cc	59.57%	19 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62762      +/-   ##
==========================================
- Coverage   89.69%   89.59%   -0.10%     
==========================================
  Files         706      706              
  Lines      218143   218147       +4     
  Branches    41730    41687      -43     
==========================================
- Hits       195655   195459     -196     
- Misses      14401    14586     +185     
- Partials     8087     8102      +15     

Files with missing lines	Coverage Δ
lib/ffi.js	96.56% <100.00%> (+0.71%)	⬆️
src/node_errors.h	86.48% <ø> (ø)
src/node_ffi.h	72.72% <ø> (ø)
src/ffi/types.cc	59.82% <59.57%> (+0.14%)	⬆️
src/node_ffi.cc	69.04% <46.80%> (-0.04%)	⬇️
src/ffi/data.cc	71.06% <41.17%> (-7.72%)	⬇️

... and 52 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[meixg]

LGTM
One small API thought: would it be better to expose this as something like getRawReference() instead of getRawPointer(), returning both the pointer and byteLength? For byte sources, the pointer is usually
meant to be used together with its length.

[ShogunPanda]

@meixg I don't think it is acually necessary. When using the function you already own the source (getRawPointer(buffer)) so you can call the byteLength directly, isn't it?