Handle results of async operations triggered from within `withHandlers` in correct order

If user triggers an async operation method, such as fetching data from the server, there's no specific time when the result will arrive and be processed. It's not a problem while there's only one async process running. But when two or more requests are running, then we cannot guarantee that the last result to arrive is from the request that was sent last.

This is how it can look over time:

```
Time ------------------------------------------>
Request #1 -----REQ1--------------------------RESP1-->
Request #2 ------------REQ2-------RESP2-------------->
```

Multiple requests can be a result of user triggering fetching too frequently, or the server responding too slowly. It's the things beyond developer's control, but the code should handle those cases.

Example of the code having the issue. `props.setRows(res.data)` can be executed at any time, even when result for the response which is no longer relevant arrives. And as the result, wrong info will be displayed to the user:

```js
withHandlers({
fetchRows: (props, app) => (params) => {
props.setLoading(true);

app.get('api').getData(params)
.then((res) => {
props.setRows(res.data);
props.setLoading(false);
})
.catch((error) => {
props.setErrorMessage(error.message);
props.setLoading(false);
});
}
});
```

Generally, it's preferred to handle the result of the last request, ignoring all previous requests (or cancelling them). This is generally the approach for read operations. It's the logic that `switchMap` has.

While for write operations, you might want to queue them (`concatMap`) or receive all responses asynchronously (`mergeMap`).

So the question is how we can support such logic with current API or by changing API that we have?

The issue does not name files or tests. Begin by tracing the withHandlers API and its async handler contract, then compare the requested ordering behavior with RxJS switchMap, concatMap, and mergeMap. Done criteria are an agreed API behavior for stale, queued, and concurrent results, with coverage for each mode.

Written by the indexing model from the issue text.