More testing for ANALYZE stmt and JSON

Development tasks:
MDEV-406 ANALYZE $stmt
MDEV-6388 ANALYZE $stmt output in the slow query log
MDEV-6382 ANALYZE $stmt and security
MDEV-6109 EXPLAIN JSON

Need to check also for

• Replication (ANALYZE may have an effect. Is it properly binlogged. Can a slave thread run ANALYZE stmt command?)
• Nested VIEWs and single-table UPDATE/DELETE (check EXPLAINs)

  <spetrunia>: there was a problem with printing table names in ANALYZE
  <spetrunia>: it was resolved
  <spetrunia>: but I still had doubts.. so, it would be nice to make a testcase that would use nested update-able VIEW
  <spetrunia>: then run EXPLAIN UPDATE/DELETE on it
  <spetrunia>: then run ANALYZE UPDATE/DELETE
  <spetrunia>: and check that the ouptuts match
  <spetrunia>: the problem was : it used to print table aliases (as defined by the VIEW)
  <spetrunia>: and not table names
  <spetrunia>: or was it vice versa
  <spetrunia>: anyhow, it was not what EXPLAIN printed
  <spetrunia>: I don't think it's needed to spend much time on this..
  <spetrunia>: create a test case; let view definitions use table aliases
  <spetrunia>: which are different from the table names
  <spetrunia>: if it works, ok

• PS (binary protocol)
• Get testcases for MDEV-6382
• Whether the fact that even basic statements, like "INSERT INTO tbl VALUES ('foo')" will have their "EXPLAIN" printed into the slow query log. This is a consequence of them having EXPLAINs. Do we need a feature that avoids printing 'degenerate' query plans into the slow query log?