Between 5.0 and 5.1, the step of incrementing the global query id
changed, which broke how the profiler noticed when a new query had
started.  That reset the state list and caused all but the last 
five (or so) states to be thrown away.

Now, don't watch for query_id changes in the lower level.

Add a bogus state change at the end of profiling so that the last 
real state change is timed.

Emit source reference for the start of the span of time instead of
the end of it.


mysql-test/r/profiling.result:
  Add a test that shows continuation of execution with multi-statement
  packets.
mysql-test/t/profiling.test:
  Add a test that shows continuation of execution with multi-statement
  packets.
sql/sql_parse.cc:
  Insert profiling calls at beginnings and ends of each query.
  
  Remove the old way of keeping or discarding profiles, and flipping 
  to new query profiles.
sql/sql_profile.cc:
  No longer use the thread's query_id to determine when we flip
  to a new statement.
  
  Some status statements are set to be NULL in the server.  We don't
  log those, as it doesn't fit this style of profiling yet.
  
  Rewrite the parser code to be more active and legible.  
  
  Relying on passive/lazy discovery of new queries was buggy.
  
  Add a bogus status change before ending a profile, so that the 
  previous real status has a endpoint.
  
  Emit source reference of the start of the span-of-time instead of
  the end of it.
sql/sql_profile.h:
  Store the server_query_id at instantiation time for a new query.
  
  Rewrite the parser code to be more active.  Relying on passive/lazy
  discovery of new queries was buggy.
  
  Name first state to more honestly describe the state.  We don't 
  really know of initialization that will follow.
sql/sql_show.cc:
  Update comment to note the decidedly weird field_length behavior
  on Decimal types in information_schema.