Allow retrieving query traces over HTTP

[lutter]

With these changes, if the request header X-GraphTraceQuery is set to the right value, the response to a GraphQL query will include a trace of the SQL queries that were run to generate the GraphQL response. That trace looks like

{
  "data": { .. },
  "trace": {
    "query": "<GraphQL query>",
    "query_id": "e89d81e9ce262e07-d019a5d7d56a8920",
    "block": 10096796,
    "elapsed_ms": 6,
    "pairs": {
      "query": "/* controller='filter',application='sgd44',route='e89d81e9ce262e07-d019a5d7d56a8920',action='10096796' */\tselect 'Pair' as entity, to_jsonb(c.*) as data from (select  * \t  from \"sgd44\".\"pair\" c\t where c.block_range @> $1\t\t order by \"id\", block_range\t limit 2) c -- binds: [10096796]",
      "elapsed_ms": 0,
      "entity_count": 2,
      "token0": {
        "query": "<SQL query>",
        "elapsed_ms": 0,
        "entity_count": 2
      },
      "token1": {
        "query": "<SQL query>",
        "elapsed_ms": 0,
        "entity_count": 2
      }
    },
    "tokens": {
      "query": "<SQL query>",
      "elapsed_ms": 0,
      "entity_count": 2
    }
  }
}

Since generating traces can be expensive, the right value for X-GraphTraceQuery is configurable through the environment variable GRAPH_GRAPHQL_TRACE_TOKEN; only if the header contains that token will a trace be generated.

This PR also simplifies the usage of graphman query: it is no longer necessary to set GRAPH_LOG_QUERY_TIMING when running it to get the query output and trace from the command line. The JSON that graphman query generates as a trace is the same as is returned for HTTP queries, and much more readable than it was before.

[leoyvens]

Nice! I didn't know we had these traces