Add onDataOrAborted and onWritableOrAborted

[nigrosimone]

The JS side of uNetworking/uWebSockets#1954 (submodule bumped to it), HTTP/1 only. Nothing changes for existing code. In JS they have their own names, because an overload would need the arity of the callback, ~70 ns per call for everybody.

res.onDataOrAborted((res, chunk, maxRemainingBodyLength) => {}) and res.onWritableOrAborted((res, offset) => true) get res first and null on abort, until the response ends, so onAborted is not needed. The functions live in two new internal fields of res, like onAborted.

On Node 26, per call: onData and onWritable cost the same as master (~58 and ~50 ns), onDataOrAborted alone ~58 ns against ~120 ns for onAborted + onData.

Upload.mjs now uses onDataOrAborted, the types are in docs/index.d.ts.

[github-actions]

Benchmark: f1c5836 against 27c8955

Scenario	Base req/s	Head req/s	Head / base	Rounds	Noise	Busy	CPU per request
http/hello-world	111606	113259	1.013x (+1.3%)	1.01 to 1.03	±1.4%	100% / 100%	8.95 / 8.82 us (0.987x)
http/headers	96937	97128	0.998x (-0.2%)	0.99 to 1.01	±2.2%	100% / 100%	10.31 / 10.29 us (1.002x)
http/json-post	81577	83935	1.030x (+3.0%)	1.02 to 1.03	±5.7%	100% / 100%	12.25 / 11.90 us (0.971x)
http/cached	128707	129641	1.007x (+0.7%)	1.01 to 1.01	±1.1%	100% / 100%	7.77 / 7.71 us (0.993x)
ws/echo-20b	117400	118171	1.006x (+0.6%)	0.99 to 1.01	±2.1%	100% / 100%	8.51 / 8.45 us (0.993x)
ws/echo-4kb	109802	109917	1.002x (+0.2%)	1.00 to 1.01	±2.3%	100% / 100%	9.10 / 9.09 us (0.998x)

4 rounds of 3s per scenario, each round loading base, head and a second process of each one, from a copy of its build, after the other, in an order that changes every round. "Head / base" is the median of the per-round ratios of req/s and "Rounds" their range. "Noise" is how far base/base and head/head, the same code on both sides, got from 1 in this same run: that is what the machine did, so a row is marked only when the median moved further than that, at least 2%, and every round moved the same way: 👀 slower, 🏆 faster. "Busy" is the cpu time of the server process over the round and "CPU per request" that time divided by the requests it answered, with the head/base ratio judged against its own same-code band and bold when it cleared it. When busy is well under 100% the load generator set the pace, the req/s are its and the cpu per request is the column to read. Only the ratios are comparable across runs, the absolute figures depend on the runner.

Node v26.10.0, AMD EPYC 7763 64-Core Processor, 4 cores (server on cpu 0, load on 2,3), http_load_test and load_test with 100 connections.