Observers no longer running in calling goroutine

### What version of Cassandra are you using?

n/a

### What version of Gocql are you using?

aa46e85d0a7f8496b2fe83e9b551a63a550604d2

### What did you do?

Ran the tests for https://github.com/elastic/apm-agent-go/tree/0.5/module/apmgocql, and they failed due to https://github.com/gocql/gocql/pull/1178/files.

### What did you expect to see?

I expected the stack trace for an observed query to originate from the calling code.

This package provides an Elastic APM tracing observer for gocql queries. One of the things we do is report the stack trace when a query fails, or when a query is unusually slow. Ideally the stack trace would originate in the user's code, so the error/slowdown can be tied back to it.

### What did you see instead?

The tests failed as the observed query now executes in another goroutine, as of https://github.com/gocql/gocql/pull/1178.

Ideally for us, the observer would execute in the same goroutine as the user's code.

Start by running the apmgocql tests mentioned in the issue and inspect the observer execution path affected by gocql PR 1178. Compare the callback's goroutine with the user's calling goroutine; done means observed queries execute in the calling goroutine and the stack-trace tests pass.

Written by the indexing model from the issue text.