Investigate "t" Response Type Ordering for Crazy Fast Response Routing

Asked on slack `#driver-dev`:

Hey there... was thinking more about the performance of the C# driver... I was wondering, at the protocol level, is there assurance that the JSON response string will always have the `"t"` (`Response` type) first before the response error `"e"` and data `"r"` properties? Example response:

```
{"t":1,"r":[true]}
```

If so, I think I can pull off some crazy optimizations tricks by figuring out the `Response` type without actually having to parse the full JSON string. This would allow me to route the JSON response though the driver knowing it's response type to its proper destination for parsing. Might allow the use of Intel SIMD/CPU vectorization too. Check this out:

```
{"t":1,"r":[true]}
{byte[18]}
[0]: 123 {
[1]: 34 "
[2]: 116 t
[3]: 34 "
[4]: 58 :
[5]: 49 1
[6]: 44 ,
[7]: 34 "
2462397222020719227 (C# long, 64-bits, 8 bytes, representation)
```

So, all I'd need to do is mask bytes 5 and 6 to figure out what the response type is when I read the first `Long` bytes of the response stream. Actually, it's there already, as a compile-time constant. :smile: Let me know. Thx.

Start with the protocol-level response format and the #driver-dev discussion described in the issue; no repository file or test is identified. Determine whether the t property is guaranteed to precede e and r, and document the result and any safe routing implications.

Written by the indexing model from the issue text.