This reduces the complexity of implementing async hosts such as mosn by
splitting the guest export "handle" into "handle_request" and
"handle_response".

* `handle_request`: called by the host on each request and returns `next=1` to
  continue to the next handler on the host.
* `handle_response`: caller by the host, regardless of error, when
  `handle_request` returned `next=1`.

The `next` field is combined with an optional `reqCtx` as the i64 result
of `handler_request`.

When the guest decides to proceed to the next handler, it can return
`ctxNext=1` which is the same as `next=1` without any request context. If it
wants the host to propagate request context, it shifts that into the upper
32-bits of ctxNext like so:

```go
ctxNext = uint64(reqCtx) << 32
if next {
	ctxNext |= 1
}
```

** Impact of the new design

This results in the same amount of calls between the guest and the host,
as "next" is no longer needed. This also allows the guest to be called
regardless of host failure, for example in logging interceptors. On the
other hand, splitting the ABI may feel a little more work, as you have
to define two callbacks, not one. That said, in TinyGo, the default
response callback will be invisible to those who only deal with
requests, as it can simply no-op return.

Signed-off-by: Adrian Cole <[email protected]>