implement strtotime() via timelib to make it identical to PHP strtotime()

[quasilyte]

PHP uses timelib more intensively and we could replace some of out
lookup tables from datetime.cpp with its help, but it might be a better
idea to do this (if ever) later.

This patch also includes a fix to date_default_timezone_get(),
so if anyone uses a date_default_timezone_set() with a supported
argument, calling date_default_timezone_get() would return that value.

Timelib: https://github.com/derickr/timelib
For this WIP I used this fork (cmake is added): https://github.com/quasilyte/timelib/tree/kphp
The fork has 0 changes except for the added CMake file.

TODO:

• Create a timelib-kphp-vk package for it (like curl-kphp-vk)
• Move that fork to vkcom organization
• Can we do a library lookup better instead of using a hardcoded paths?
• Update the "build from sources" docs
• Make sure it works on macos

Benchmark results:

name             old time/op  new time/op   delta
Now              1.62µs ± 1%   5.33µs ± 0%  +229.20%  (p=0.016 n=5+4)
Timestamp        2.20µs ± 1%  20.37µs ± 0%  +825.27%  (p=0.008 n=5+5)
10September2000  2.10µs ± 1%   6.86µs ± 1%  +225.76%  (p=0.008 n=5+5)
NextMonday       1.83µs ± 1%   7.04µs ± 1%  +284.92%  (p=0.008 n=5+5)
TimeWithOffset   7.32µs ± 1%   8.59µs ± 0%   +17.41%  (p=0.008 n=5+5)
[Geo mean]       2.51µs        8.53µs       +239.11%

Benchmarks:

<?php

class TimelibBenchmark {
    public function benchmarkNow() {
        return strtotime("now");
    }

    public function benchmarkTimestamp() {
        return strtotime("91248374");
    }

    public function benchmark10September2000() {
        return strtotime("10 September 2000");
    }

    public function benchmarkNextMonday() {
        return strtotime("last Monday");
    }

    public function benchmarkTimeWithOffset() {
        return strtotime("+1 week 2 days 4 hours");
    }
}

[AlexK0]

timelib_free call is not the main issue. The main issue is an invalid internal library state. If you sure, that timelib doesn't use any static/global vars inside (which can be spoiled with signal interruption), then we don't need a CriticalSectionGuard here, otherwise we must use the guard.

And if you add the guard, the second question is: Is timelib ready for nullptrs from malloc family calls?

[quasilyte]

I updated the comment.

• timelib can't handle nullptr from malloc gracefully
• timelib is thread-safe

So it looks like CriticalSectionGuard is not needed here.

[quasilyte]

I addressed the review comments, but the CI build failed.
I'll remove the WIP prefix when it will be clear that failure was unrelated (or fixed).