WL#3001: Consistent handling of CURRENT_USER in DEFINER execution context

The DEFINER of a stored routine/view/trigger is
stored, so that the definer's privileges can be
used during execution if necessary. When this
happens, the value of CURRENT_USER is changed
to show the definer and not the invoker. But 
this change is not consistent over all statements;
this task is to ensure that context changes to
CURRENT_USER are handled consistently.

Some statements allow a DEFINER to be executed:

- SQL SECURITY DEFINER characteristic for stored procedures and functions
- SQL SECURITY DEFINER characteristic for views
- CREATE TRIGGER has a DEFINER clause

This causes the object to execute within a context that uses the definer's
privileges rather than the invoker's privileges.

For such objects, the meaning of the CURRENT_USER() function changes
when executing in a context that uses the DEFINER privilege: It returns
the definer account, not the invoker account.  For example,
SELECT CURRENT_USER() returns a value that changes in definer execution
context.

However, we have an inconsistency relating to CURRENT_USER().
For example, if you execute SHOW GRANTS FOR CURRENT_USER(),
the output does *not* change in definer execution context.
(For example, the output does not report the definer's privileges
when the statement is executed in a SQL SECURITY DEFINER stored
routine.)

I have filed a bug report about this particular issue: BUG#15298
(SHOW GRANTS FOR CURRENT_USR: Incorrect output in DEFINER context)
However, CURRENT_USER is one of the allowable expansions of the "user"
production in sql_yacc.yy, and that production seems to be allowable in
the grammar for a number of statements.

SET PASSWORD FOR user
RENAME USER user TO user
DROP USER user
...

This means that the CURRENT_USER issue in DEFINER context should
be dealt with not just for SHOW GRANTS, but also for several other
statements.