Bug#39843 DELETE requires write access to table in subquery in where clause

An unnecessarily restrictive lock were taken on sub-SELECTs during DELETE.

During parsing, a global structure is reused for sub-SELECTs and the attribute
keeping track of lock options were not reset properly.
This patch introduces a new attribute to keep track on the syntactical lock
option elements found in a sub-SELECT and then sets the lock options accordingly.

Now the sub-SELECTs will try to acquire a READ lock if possible
instead of a WRITE lock as inherited from the outer DELETE statement.


mysql-test/r/lock.result:
  Added test case for bug39843
mysql-test/t/lock.test:
  Added test case for bug39843
sql/sql_lex.cc:
  * Reset member variable lock_option on each new query.
sql/sql_lex.h:
  * Introduced new member variable 'lock_option' which is keeping track
    of the syntactical lock option of a (sub-)select query.
sql/sql_parse.cc:
  * Wrote comments to functions.
sql/sql_yacc.yy:
  * Introduced an attribute to keep track of syntactical lock options
    in sub-selects.
  * Made sure that the default value TL_READ_DEFAULT is at the begining
    of each subselect-rule.

sql/sql_lex.h

@@ -688,6 +688,15 @@ public:
   int cur_pos_in_select_list;
 
   List<udf_func>     udf_list;                  /* udf function calls stack */
+
+  /**
+    Per sub-query locking strategy.
+    Note: This variable might interfer with the corresponding statement-level
+    variable Lex::lock_option because on how different parser rules depend
+    on eachother.
+  */
+  thr_lock_type lock_option;
+
   /* 
     This is a copy of the original JOIN USING list that comes from
     the parser. The parser :