Changed the build to use /MD flag so that DDL version of C runtime is used.

To make sure MariaDB is always runnable on target system, include
redistributable CRT libraries into installer.

For MSI package, use Microsoft's merge modules.
For ZIP  use "applocal" approach,i.e place redistributable dlls
into the bin directory of the package(via InstallRequiredSystemLibraries
cmake module) The space overhead of libraries in negligible, ~ 3MB unpacked.

There are 2 cases, where we still link C runtime statically

- Upgrade wizard, it uses MFC, and we link statically to avoid
redistribute also whole MFC (for this single application, does not
make much sense).

- MSI installer's custom action dll wixca.dll.Here, we need static link
so that MSI won't fail on a target system that does not have VC++2015
runtime already installed.

- Fixing portabibily problems in sql-common/my_time.c
  (and additionally in sql/sql_time.cc)

- Re-enabling func_time.test
  Now all new chunks added in MDEV-17351 work fine on all platforms.

Problems:

Functions LEAST() and GREATEST() in TIME context, as well as functions
TIMESTAMP(a,b) and ADDTIME(a,b), returned confusing results when the
input TIME-alike value in a number or in a string was out of the TIME
supported range.

In case of TIMESTAMP(a,b) and ADDTIME(a,b), the second argument
value could get extra unexpected digits. For example, in:
    ADDTIME('2001-01-01 00:00:00', 10000000)  or
    ADDTIME('2001-01-01 00:00:00', '1000:00:00')
the second argument was converted to '838:59:59.999999'
with six fractional digits, which contradicted "decimals"
previously set to 0 in fix_length_and_dec().
These unexpected fractional digits led to confusing function results.

Changes:
1. GREATEST(), LEAST()

   - fixing Item_func_min_max::get_time_native()
   to respect "decimals" set by fix_length_and_dec().
   If a value of some numeric or string time-alike argument
   goes outside of the TIME range and gets limited to '838:59:59.999999',
   it's now right-truncated to the correct fractional precision.

   - fixing, Type_handler_temporal_result::Item_func_min_max_fix_attributes()
   to take into account arguments' time_precision() or datetime_precision(),
   rather than rely on "decimals" calculated by the generic implementation
   in Type_handler::Item_func_min_max_fix_attributes(). This makes
   GREATEST() and LEAST() return better data types, with the same
   fractional precision with what TIMESTAMP(a,b) and ADDTIME(a,b) return
   for the same arguments, and with DATE(a) and TIMESTAMP(a).

2. Item_func_add_time and Item_func_timestamp

   It was semantically wrong to apply the limit of the TIME data type
   to the argument "b", which plays the role of "INTERVAL DAY TO SECOND" here.
   Changing the code to fetch the argument "b" as INTERVAL rather than as TIME.

   The low level routine calc_time_diff() now gets the interval
   value without limiting to '838:59:59.999999', so in these examples:
     ADDTIME('2001-01-01 00:00:00', 10000000)
     ADDTIME('2001-01-01 00:00:00', '1000:00:00')
   calc_time_diff() gets '1000:00:00' as is.  The SQL function result
   now gets limited to the supported result data type range
   (datetime or time) inside calc_time_diff(), which now calculates
   the return value using the real fractional digits that
   came directly from the arguments (without the effect of limiting
   to the TIME range), so the result does not have any unexpected
   fractional digits any more.

   Detailed changes in TIMESTAMP() and ADDTIME():

   - Adding a new class Interval_DDhhmmssff. It's similar to Time, but:
     * does not try to parse datetime format, as it's not needed for
       functions TIMESTAMP() and ADDTIME().
     * does not cut values to '838:59:59.999999'

     The maximum supported Interval_DDhhmmssff's hard limit is
     'UINT_MAX32:59:59.999999'. The maximum used soft limit is:
     - '87649415:59:59.999999'   (in 'hh:mm:ss.ff' format)
     - '3652058 23:59:59.999999' (in 'DD hh:mm:ss.ff' format)
     which is a difference between:
     - TIMESTAMP'0001-01-01 00:00:00' and
     - TIMESTAMP'9999-12-31 23:59:59.999999'
     (the minimum datetime that supports arithmetic, and the
     maximum possible datetime value).

   - Fixing get_date() methods in the classes related to functions
     ADDTIME(a,b) and TIMESTAMP(a,b) to use the new class Interval_DDhhmmssff
     for fetching data from the second argument, instead of get_date().

   - Fixing fix_length_and_dec() methods in the classes related
     to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use
     Interval_DDhhmmssff::fsp(item) instead of item->time_precision()
     to get the fractional precision of the second argument correctly.

   - Splitting the low level function str_to_time() into smaller pieces
     to reuse the code. Adding a new function str_to_DDhhmmssff(), to
     parse "INTERVAL DAY TO SECOND" values.

   After these changes, functions TIMESTAMP() and ADDTIME()
   return much more predictable results, in terms of fractional
   digits, and in terms of the overall result.

   The full ranges of DATETIME and TIME values are now covered by TIMESTAMP()
   and ADDTIME(), so the following can now be calculated:

    SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999');
    -> '9999-12-31 23:59:59.999999'

    SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999')
    -> '9999-12-31 23:59:59.999999'

    SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998');
    -> '838:59:59.999999'

This was a bug in the code of MDEV-12387 "Push conditions into materialized
subqueries". The bug manifested itself in rather rare situations. An
affected query must contain IN subquery predicate whose left operand
was an outer field of a mergeable derived table or view and right operand
was a materialized subquery.
The erroneous code in fact stripped off the Item_direct_ref wrapper from
the left operand of the IN subquery predicate when building equalities
produced by the conversion of the predicate into a semi-join. As a result
the left operand was not considered as an outer reference anymore and
used_tables() was calculated incorrectly. This caused a crash in the
function optimize_keyuse().

 - remove function prototype for shared memory (no more used), and VIO
members that are unused
 - Do not call DisconnectNamedPipe on pipe handle. CloseHandle() is enough.

Remove threads that are doing nothing but wait
- main thread now handles the connections
(if threadpool is used, also threadpool threads would wait for connections)
- thread for socket and pipe connections are removed
- shutdown thread is now removed, we wait for shutdown
notification in main thread as well
- kill_server() is also called inside the main thread, after connection
loop finished.

btr_cur_instant_root_init(): Check the "infimum" and "supremum"
record strings already here, and not later in btr_cur_instant_root_init().
In this way, we can properly reject files from later versions where
instant ALTER TABLE could support further operations that change the
format of InnoDB clustered indexes.

Because changes of the FIL_PAGE_TYPE or PAGE_INSTANT in the root
page are not undo-logged, it is possible that the fields suggest
that instant ADD COLUMN is in effect, even though no metadata
record exists. If the fields are set, proceed to fetch the
metadata record. If the metadata record does not exist, return
success if !index->is_instant().

Also, check that the "infimum" and "supremum" records carry the
strings in the root page. In a later format that supports instant
DROP COLUMN, we will have to store more information in the root
page, so that index->n_core_null_bytes can be determined accurately.

btr_cur_instant_init_low(): If columns were instantly added and dropped,
then index->is_instant() might not hold even though the root page type
was FIL_PAGE_TYPE_INSTANT. MariaDB 10.3 must refuse to open such files,
because instant DROP COLUMN is not supported.

Also, refuse to open the table if the metadata record has
wrong info OR status bits. Previously, we only refused to open
if both bits were wrong.

MDEV-16211 Contents of transaction_registry should not be replicated by Galera

Addition based on Travis results

             truncating a temporary table

TRUNCATE expects only one TABLE instance (which is used by TRUNCATE
itself) to be open. However this requirement wasn't enforced after
"MDEV-5535: Cannot reopen temporary table".

Fixed by closing unused table instances before performing TRUNCATE.

Patch fixes two bugs:
1) BEGIN_TIMESTAMP of MYSQL.TRANSACTION_REGISTY is '0-0-0' on replication record insertion
2) BEGIN_TIMESTAMP equals COMMMIT_TIMESTAMP in MYSQL.TRANSACTION_REGISTRY

Fixed by calling THD::set_time() at appropriate places

A cleanup for MDEV-17317 Add THD* parameter into Item::get_date() and stricter data type control to "fuzzydate"

Fixing C++ function check_date() to get the "fuzzydate" as
date_mode_t rather than ulonglong, so conversion from
date_time_t to ulonglong is now done inside C++ check_date(),
and no conversion is needed in the callers' code.

As an additional safety, modified the code not to pass
TIME_FUZZY_DATE to the low level C functions:
- check_date()
- str_to_datetime()
- str_to_time()
- number_to_datetime()
because TIME_FUZZY_DATE is known only on the C++ level,
C functions do not know it.

Soon we'll be adding more flags into the C++ level (i.e. to date_time_t),
e.g. for rounding. It's a good idea to prevent passing C++ specific
flags into pure C routines before this change.

Asserts were added into the affected C functions to verify
that the caller passed only known C level flags.

rec_offs_nth_extern_old() was introduced in
commit a4948daf
and never used.

Also fixes:
MDEV-17330 Wrong result for 0 + LEAST(TIME'-10:00:00',TIME'10:00:00')

Problems:

1. These methods did not take into account the current session date flags
and passed date_mode_t(0) to func->get_date():

Type_handler_temporal_result::Item_func_min_max_val_real
Type_handler_temporal_result::Item_func_min_max_val_int
Type_handler_temporal_result::Item_func_min_max_val_decimal

Fixing to pass sql_mode_for_dates(thd) instead of date_mode_t(0).
Note, sql_mode_for_dates(thd) is only needed for DATE/DATETIME
data types. It is not needed for TIME.
So splitting value methods Type_handler_temporal_result::Item_func_min_max_xxx
into individual implementations for
Type_handler_{time|date|datetime|timestamp}_common
and, instead of calling get_date(), reusing inside classes
Time(), Date(), Datetime() and their methods to_longlong().
sql_mode_for_dates(thd) is automatically passed to get_date()
inside Date() and Datetime() constructors.

The switch to classes also fixed the problem reported in MDEV-17330.
Type_handler_temporal_result::Item_func_min_max_val_int() used to
call TIME_to_ulonglong(), which was not correct for TIME.
Changing the code to use Time().to_longlong() solved this.

2. Type_handler_temporal_result::Item_func_min_max_get_date
also did not take into account the current session
date flags in case of conversion from DATE/DATETIME to time
and passed date_mode_t(0) to get_date_native().
Fixing to pass sql_mode_for_dates(thd) in case of conversion
from DATE/DATETIME to TIME.

MDEV-15406 NO_ZERO_IN_DATE erroneously affects how CAST(AS DATE) warns about fractional digit truncation

MDEV-17219 Assertion `!t->fraction_remainder(decimals())' failed in Field_time::store_TIME_with_warning

storage/rocksdb/rdb_datadic.cc: In member function 'int myrocks::Rdb_key_def::unpack_integer(myrocks::Rdb_field_packing*, Field*, uchar*, myrocks::Rdb_string_reader*, myrocks::Rdb_string_reader*) const'
storage/rocksdb/rdb_datadic.cc:1781:1: internal compiler error: Segmentation fault
 }

on ppc64le, ubuntu bionic gcc 7.3.0 and debian stretch gcc 6.3.0

The error happens with -ftree-loop-vectorize when trying to vectorize
a particular loop (see Rdb_key_def::unpack_integer())

Compiler gets confused by __attribute__((optimize("O0")) that comes from
ha_rocksdb_proto.h. The intention of this __attribute__ was to prevent
function from being inlined (see ha_rocksdb.cc). Let's use a more
specific attribute that prevents inlining but does not confuse
loop vectorizer.