WL#6059: Make RIGHT JOIN be fully converted to LEFT JOIN

Currently, if using a RIGHT JOIN, some internal objects are not converted to
LEFT JOIN: some lists of tables built at parse time don't have their order
reversed (only the order of "join list" is).
Which forces us to remember that this LEFT JOIN was originally a RIGHT JOIN and
have some specific code, after parsing, for this (search for JOIN_TYPE_RIGHT in
sql/).
This half-transformation causes bugs, like: BUG#12567331 (closed in 2011),
BUG#21350125 (show-stopper for 5.7.9, fixed with a hack in 2015).
The task is to do the necessary reversals at parse time, so that after parsing,
the RIGHT JOIN is in all respects a LEFT JOIN.

As it's a pure code refactoring:

F-1 Results and performance of queries should not be affected

During parsing, the PT_joined_table object is created.

Post-WL, in its contextualize_tabs(), if the join type is JTT_RIGHT, we swap
tab1_node and tab2_node before contextualizing them. Thus, 
T1 RIGHT JOIN T2
becomes exactly like
T2 LEFT JOIN T1,
as far as the lists "next_local", "next_name_resolution_table" and "SELECT_LEX::join_list" are concerned (insisting: post-WL these lists enumerate
tables in the same order as if the LEFT JOIN had been typed).

This is different from the pre-WL situation where the swapping happened right
after contextualize_tabs, and was done only on "join_list": thus, "next_local"
and "next_name_resolution_table" were as in the original query, while
"SELECT_LEX::join_list" was as in the converted query.

Additionally, post-WL the PT_joined_table object gets its flag JTT_RIGHT changed
to JTT_LEFT at contextualize_tabs; and we record, in the right-side argument
of the now-LEFT JOIN, that it had a swapping (tr2->join_order_swapped=true), and
that the SELECT_LEX had a swapping (more on this below).

The
enum Outer_join_type {
  JOIN_TYPE_INNER = 0,
  JOIN_TYPE_LEFT = 1,
  JOIN_TYPE_RIGHT = 2
};
is replaced with a bool. In essence it means JOIN_TYPE_RIGHT is gone.

Because "next_name_resolution" and "join_list" are in consistent order now,
TABLE_LIST::first_leaf_for_name_resolution() and TABLE_LIST::last_leaf_for_name_resolution() don't need special-casing for RIGHT
JOIN and are thus simplified.
Likewise, store_top_level_join_columns() is simplified.

propagate_table_maps() and check_right_lateral_join() are removed.
The former was a helper for the latter. The latter was necessary to handle this:
select * from t0, t1 right join lateral (select t1.a) as dt;
Consider first this:
select * from t0, lateral (select t1.a) as dt left join t1;
As LATERAL "looks to the left only", it failed in usual name resolution code, saying t1.a is unknown. Which is correct.
Back to:
select * from t0, t1 right join lateral (select t1.a) as dt;
Pre-WL we found t1.a as t1 is to the left _and_ the name resolution code used 
next_name_resolution_table list which is t0-t1-dt; still this was an invalid query as it cannot be executed (it would require to read t1 first, even though
it's on the NULL-complementable side of the join).
So, pre-WL, such query needed a special detection, in check_right_lateral_join().
Post-WL next_name_resolution_table list is t0-dt-t1 and thus the query fails in
usual name resolution code, saying t1.a is unknown. Just like the LEFT JOIN
variant.
So check_right_lateral_join() is removed.

SELECT_LEX::convert_right_join() is removed, as the conversion is done differently now.

That was for the good side of the WL: scattered code and complexity is removed.

There is one place, though, where additional complexity comes in: it's insert_fields(). That function's job is to do, in the SELECT list, the expansion 
of 'table_name.*' (qualified asterisk) or '*' (unqualified).
First, here is some background.

  SELECT * FROM T1 RIGHT JOIN T2 ON ;
  is converted, during contextualization, to:
  SELECT * FROM T2 LEFT JOIN T1 ON ;
  however the former has to return columns of T1 then of T2,
  while the latter has to return T2's then T1's.
  Post-WL, the conversion is complete: the lists 'next_local',
  'next_name_resolution_table' and SELECT_LEX::join_list are as if the user
  had typed the second query.

Now to the problem: pre-WL, insert_fields() would always find the user-input order in next_local or next_name_resolution_table; post-WL, if there was a RIGHT 
JOIN, the user-input order is nowhere readily available.
Thus, post-WL, if:
- the user-input order is necessary in insert_fields() i.e. it's expanding an
unqualified '*' (for qualified 'table.*' it does matching by table name so
doesn't care for order of tables)
- and there was any RIGHT JOIN in the query block
- then we have to calculate the user-input order, by going through join_list
(diving down in join nests), and for that we need to know that a certain join
nest isn't in the user-input order. That's why in contextualize_tabs() we took a note of the reversal.

So we are still keeping a trace that it was a RIGHT JOIN, but the intention is
that this trace should serve *only* in insert_fields(). And if it stays so, the
WL is a net gain, as the complexity has been removed from several places, has 
been confined to insert_fields(), and new code should be able to never have to care about right joins.