Bug#29816 Syntactically wrong query fails with misleading error message

The core problem is that an SQL-invoked function name can be a <schema
qualified routine name> that contains no <schema name>, but the mysql
parser insists that all stored procedures (function, procedures and
triggers) must have a <schema name>, which is not true for functions.
This problem is especially visible when trying to create a function
or when a query contains a syntax error after a function call (in the
same query), both will fail with a "No database selected" message if
the session is not attached to a particular schema, but the first
one should succeed and the second fail with a "syntax error" message.

Part of the fix is to revamp the sp name handling so that a schema
name may be omitted for functions -- this means that the internal
function name representation may not have a dot, which represents
that the function doesn't have a schema name. The other part is
to place schema checks after the type (function, trigger or procedure)
of the routine is known.


mysql-test/r/sp-error.result:
  Add test case result for Bug#29816
mysql-test/r/udf.result:
  Add test case result for Bug#28318
mysql-test/t/sp-error.test:
  Add test case for Bug#29816
mysql-test/t/udf.test:
  Add test case for Bug#28318
sql/sp.cc:
  Copy the (last) nul byte of the stored routine key and move name parsing
  code to the sp_name class constructor.
sql/sp_head.cc:
  Revamp routine name parsing for when no schema is specified and
  omit dot from the qualified name if the routine is not associated
  with a scheme name.
sql/sp_head.h:
  Name parsing got bigger, uninline by moving to a single unit -- the sp_head.cc
  file.
sql/sql_yacc.yy:
  Only copy the schema name if one is actually set and check for schema
  name presence only where it's necessary.