Related discussion #223

We already improved it in #224, this PR makes it more secure by

1. Renaming explainQuery to unsafeExplainQuery while the single query check and transaction wrapping is pretty secure already, there might be edge cases where a query escapes the designated boundaries. Therefore, we rename the tool to unsafeExplainQuery
2. Create a new tool called safeExplainQuery, this operates on queryId and fetches the actual SQL from pg_stat_statements table itself thereby eliminating the code path that can lead to any SQL injection. This is done in the following stacked PR Implement safe explain #226
3. Use the new safeExplainQuery tool instead of unsafeExplainQuery, to make it work, we had to additionally return queryId from getSlowQueries tool in addition to the slow SQL query. This is done in the following stacked PR Use safe explain tool #227