Timestamps are parsed as UTC when there is no system-wide tzinfo data

When there is no tzinfo database on the system, three tests related to parsing timestamps fail:

---- types::tests::parse_timestamp_auto stdout ----
thread 'types::tests::parse_timestamp_auto' panicked at 'assertion failed: `(left == right)`
  left: `Ok(2001-02-03T11:05:06Z)`,
 right: `Ok(2001-02-03T04:05:06Z)`', src\types.rs:291:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.                                                      
---- types::tests::timestamp_conversion stdout ----
thread 'types::tests::timestamp_conversion' panicked at 'assertion failed: `(left == right)`
  left: `Ok(Timestamp(2001-02-03T11:05:06Z))`,
 right: `Ok(Timestamp(2001-02-03T04:05:06Z))`', src\types.rs:274:9                                                                  
---- types::tests::timestamp_param_conversion stdout ----
thread 'types::tests::timestamp_param_conversion' panicked at 'assertion failed: `(left == right)`
  left: `Ok(Timestamp(2001-02-03T11:05:06Z))`,
 right: `Ok(Timestamp(2001-02-03T04:05:06Z))`', src\types.rs:282:9

Maybe we need to bundle timezone info into the Vector binary, although it is has some drawbacks (mainly because timezone info changes quite frequently, and it would require the user to update Vector in case of such changes).

Start in src/types.rs at the timestamp-related tests around lines 274-291 and run parse_timestamp_auto, timestamp_conversion, and timestamp_param_conversion without system-wide tzinfo data. Trace how timestamp parsing obtains timezone information; done means these tests produce the expected UTC values when the system database is unavailable.