Document hidden troubleshooting tools

RethinkDB has some hidden interfaces that are useful for testing, troubleshooting, or debugging. We should mention these in the documentation, but make it clear that they are not officially supported and may change without warning.

• The rethinkdb._debug_stats system table displays some internal stats. It's similar to rethinkdb.stats, but much more detailed and also much less user-friendly. This information can help the RethinkDB engineers troubleshoot some performance problems.
• The rethinkdb._debug_table_status system table displays detailed status information for each table, similar to rethinkdb.table_status. This information can help the RethinkDB engineers troubleshoot issues with tables getting "stuck" and not becoming available.
• The rethinkdb._debug_scratch system table acts like a regular table except that it's not written to disk or replicated over the network. Some of the RethinkDB integration tests use it.
• If read_mode is set to "_debug_direct", RethinkDB will read directly from whatever data is stored locally on the server that received the query, bypassing the normal cluster query routing infrastructure. If the table is sharded, the resulting data may be incomplete. Some of the RethinkDB integration tests use this to confirm that the data is stored on the right servers. Because this interface bypasses the normal cluster query routing infrastructure, it can also be used as a last resort to access data if there is a bug in the query routing infrastructure that prevents read_mode="outdated" from working.

Start by locating the documentation pages covering system tables and query read modes, then review the four hidden interfaces listed in the issue. Done means each interface is documented with its troubleshooting or testing purpose and a clear warning that it is unsupported and may change without notice.