When using DjangoDebugMiddleware, debug tracking presumes cursor.execute argument is a string, raising an error

* **What is the current behavior?**

When using the `DjangoDebugMiddleware`, Graphene Django wraps `cursor.execute` calls in a class that logs the query. Among the properties it logs is `is_select`, which attempts to guess if a query is a select query by looking for "select" in the argument to `cursor.execute`:
```
"is_select": sql.lower().strip().startswith("select"),
```

When `cursor.execute` is called with a non-string argument, such as a [psycopg2 query template]( https://www.psycopg.org/docs/sql.html#module-psycopg2.sql), this raises an error:
```python
from django.db import connection
from psycopg2 import sql

with connection.cursor() as cursor:
query = sql.SQL("SELECT * FROM {table}").format(table=sql.Identifier("my_table"))
cursor.execute(query)
```
This raises:
```
graphql.error.located_error.GraphQLLocatedError: 'Composed' object has no attribute 'lower'
```

* **What is the expected behavior?**
Grahene Django should not presume that the argument to `connection.cursor()` will always be a string, and do appropriate string coercion as needed before calling string methods on it.

* **What is the motivation / use case for changing the behavior?**
Robustness. It's ideal not to throw exceptions from normal uses of core Django methods which graphene-django monkeypatches.

* **Please tell us about your environment:**
- Version: graphene-django 2.5.0
- Platform: Ubuntu Linux 18.04, Django 2.2.12, graphene 2.1.8

Untersuche DjangoDebugMiddleware, wo Aufrufe von cursor.execute umschlossen werden und der Wert is_select aus dem SQL-Argument berechnet wird. Reproduziere das psycopg2.sql.Composed-Beispiel aus dem Issue und überprüfe anschließend, dass Abfrageobjekte, die keine Strings sind, den Tracking-Code nicht mehr zum Auslösen eines Fehlers bringen, während String-Abfragen ihr bisheriges Verhalten beibehalten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.