Fix some problems in the TC_LOG_MMAP commit processing, which could
lead to assertions in some cases.

Problems are mostly reproducible in MariaDB 10.0 with asynchroneous
commit checkpoints, but most of the problems were present in earlier
versions also.

followup fixes for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

Take into account that length of strings passed down to this function can be up to FN_REFLEN+1 bytes. including terminating zero.
The overwrite was caused by incomplete fix to MySQL Bug # 44834

If triggers are used for an insert/update/delete statement than the values of
all virtual columns must be computed as any of them may be used by the triggers.

add a test case for MySQL Bug #13889741: HANDLE_FATAL_SIGNAL IN _DB_ENTER_ | HANDLE_FATAL_SIGNAL IN STRNLEN

Made information_schema_all_engines stable by adding "sorted_result".

mysql-test/r/partition.result:
  Added test case
mysql-test/t/partition.test:
  Added test case
sql/ha_partition.cc:
  Removed printing of not initialized variable
storage/maria/ha_maria.cc:
  Don't copy variables that are not initialized

storage/maria/ma_test2.c:
  Problem was that rnd() generated bigger value than allocated array

Empty result after reading const tables now works for subqueries.

Check ability of index to be NULL as it made in MyISAM. UNIQUE with NULL could have several NULL entries so we have to continue even if ve have found a row.

 - Fix some warnings in newer GCC (-Werror ...).
 - Fix wrong STACK_DIRECTION detected by configure due to compiler inlining.

Analysis:
The queries in question use the [unique | index]_subquery execution methods.
These methods reuse the ref keys constructed by create_ref_for_key(). The
way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
store_key elements that represent constants. In particular it doesn't store
the store_key for NULL constants.

The execution of [unique | index]_subquery calls
subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
the left IN argument into a index lookup key, is supposed to detect if
the left IN argument contains NULLs. Since the store_key for the NULL
constant is not copied into the key array, the null is not detected, and
execution erroneously proceeds as if it should look for a complete match.

Solution:
The solution (unlike MySQL) is to reuse already computed information about
NULL presence. Item_in_optimizer::val_int already finds out if the left IN
operand contains NULLs. The fix propagates this to the execution methods
subselect_[unique | index]subquery_engine::exec so it knows if there were
NULL values independent of the presence of keys.

In addition the patch siplifies copy_ref_key() and the logic that hanldes
the case of NULLs in the left IN operand.

In fill_schema_table_by_open(): free item list before restoring active arena.


sql/sql_show.cc:
  Replaced i_s_arena.free_items with DBUG_ASSERT(i_s_arena.free_list == NULL)
  (there's nothing to free in that list)