Add emscripten_fetch_attr_t.ontimeout so user defined timeouts can reliably be distinguished

First off, I apologize if anything about this is wildly silly or ignorant, as I've never written a line of JavaScript and my general knowledge of HTTP and network software at large is not much better. I've actually ended up here because I'd like to submit a change to Qt that encompasses a section which makes use of this projects Fetch API, and unfortunately think I'm stuck given the way things are handled at the moment.

This is regards to user specified timeouts.

As far as I can tell this is how the relevant invocation of this API goes currently:

```
emscripten_fetch_attr_t attr;
// Set other attributes...
attr.timeoutMSecs = X
attr.onerror = QtClass::errorHandler
// ...
emscripten_fetch(&attr, ...)
```
->
`emscripten_start_fetch(fetch, ...)`
->
Fetch.js:
`startFetch(fetch, ...)`
wraps C `onerror` within `reportError`
->
`fetchXHR(fetch, onsuccess, onerror, ...)`
`XMLHttpRequest xhr` has method `ontimeout` for receiving `XMLHttpRequest: timeout event`,
which calls `onerror`, passing in the timeout event `e`

Timeout occurs:
xhr.ontimeout -> onerror (actually `reportError` from startFetch)

This is where the issue lies.

The timeout error event being lumped into the `reportError` function is not inherently an issue as one can simply check
`e.type == 'timeout'` at that point to know the error is due to a timeout; however, this is where `e` and `xhr` in this chain die, as the dynamic call to the `onerror` function set from the C API only exposes the `fetch` instance.

I don't currently have a setup to test Wasm myself, but from what I can see in the Qt source, the `onerror` function switches on `fetch->status`, finds the value '65535', then translates it to its own enum value for an aborted operation, even though an aborted operation and timed out operation are distinct situations, despite some overlap. I'm technically assuming here as I'm extrapolating some things based on their HTTP implementation (which I can test and know gives an "aborted" status for requests that timed out), but it seems to be the same for this

Even if I'm a bit off with the exact HTTP status code that happens to be present in this case, it appears to me regardless that there is no concrete, reliable way to detect that a fetch was terminated due to a timeout as specified in `emscripten_fetch_attr_t.timeoutMSecs`.

Absolutely correct me if I'm wrong and there is another way to do this, but otherwise it would be nice if an `ontimeout` function (void) pointer was added to the `emscripten_fetch_attr_t` struct with timeouts from XHR being forwarded there instead of `onerror` so that timeouts can be checked for explicitly in user code.