Feature runtime tzdb

[DavisVaughan]

This PR allows for setting the time zone data base directory path at runtime. It does not yet work on Windows, because there might be some code that needs to be changed in the binary tzdb parser so that it works on Windows, but is a pre-requisite step towards that.

The first 3 commits are related to <date> changes, the rest of them are civil related changes to use the custom binary location to see if things work. I fully expect the github actions builds to break, that is unrelated to these changes.

There is a new option USE_BINARY_TZDB. USE_OS_TZDB can be thought of as a subset of this. If USE_BINARY_TZDB is turned on, but USE_OS_TZDB is not, then the client is required to call set_tz_dir() before initializing the tzdb, otherwise a runtime error is thrown.

If USE_BINARY_TZDB is not defined, then it is set to USE_OS_TZDB to be compatible with all previous versions of date.

Previously, discover_tz_dir() and get_tz_dir() were always defined if on a non-Windows platform, even if USE_OS_TZDB was not defined. I considered this a bug. discover_tz_dir() is now only defined when USE_OS_TZDB is on, and get_tz_dir() is defined if either USE_OS_TZDB or USE_BINARY_TZDB is defined. It is required for this to be implemented this way to eventually add support for USE_BINARY_TZDB on Windows (i.e. we can't just turn off support for these when on Windows).

I have changed the non-Windows implementation of current_zone() to only call get_tz_dir() when USE_OS_TZDB is on. This is a direct result of the previously mentioned change. It seemed like the call to get_tz_dir() is only used in embedded systems and is related to a symlink to an OS tzdb path, so it really feels like USE_OS_TZDB should have to be active for this to work. It would not be sufficient for USE_BINARY_TZDB to be on, because this could be a custom location that the symlink probably won't point to.

[DavisVaughan]

Closed in favor of #49