Produce parseable output from unit::print for use in fixing query plans

Talking with paul.moen, he mentioned that customers used to using Oracle miss the option to save a query plan and force it's use.
https://www.dbi-services.com/blog/how-to-fix-your-own-sql-plan-in-oracle/

I mentioned to him that internally, we have the ability to output our rewritten queries and that a STRAIGHT_JOIN hint in the correct place, along with USE INDEX added to the output of this internal representation will pretty much guarantee the same execution plan despite new statistics and/or optimizer versions.

We already have a partial (and unusable) solution in explain extended select .... where the transformed query is displayed as a warning.from the manual...

EXPLAIN EXTENDED

The EXTENDED keyword adds another column, filtered, to the output. This is a percentage estimate of the table rows that will be filtered by the condition.
An EXPLAIN EXTENDED will always throw a warning, as it adds extra Message information to a subsequent SHOW WARNINGS statement. This includes what the SELECT query would look like after optimizing and rewriting rules are applied and how the optimizer qualifies columns and tables.

I propose EXPLAIN FORMAT=SQL SELECT ... which will output the transformed query complete with join order and index use fixed in the query (so updated stats or new version of server will be forced to use same join order and indexes).

There is one major wrinkle in this plan that needs to be dealt with.

IN and Exists subqueries may be transformed into semi joins. The output looks something like this

select `test`.`t1`.`pk` AS `pk` from `test`.`t1` semi join (`test`.`t2`) where `test`.`t2`.`pk` > 0

where the input looked like

SELECT pk FROM t1 WHERE (a, b) IN (SELECT a, b FROM t2 WHERE pk > 0);

The join conditions are missing and our parser doesn't know what a semi join is.

There are 2 options here

1) add a (semi) join type and print out the join conditions (add join type may not be completely trivial)
2) output the original subquery (may not work if the table pulled out of the subquery is placed earlier in the join order, completely defeating the whole object here which is repeatability).

Ideally the patch will be applicable to as earlier version as possible.