cargo audit finding on default branch

[baffling-knee]

didnt see sec contact steps in readme so opening issue instead

looks like a couple unmaintained crates, semi ok, but time has issue. chrono may not have right update and ignored issue for awhile. other project switch to time specific like Drakulix/simplelog.rs#95

Crate:     time
Version:   0.1.44
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Solution:  Upgrade to >=0.2.23
Dependency tree:
time 0.1.44
└── chrono 0.4.22
    └── fd-find 8.5.3

Crate:     ansi_term
Version:   0.12.1
Warning:   unmaintained
Title:     ansi_term is Unmaintained
Date:      2021-08-18
ID:        RUSTSEC-2021-0139
URL:       https://rustsec.org/advisories/RUSTSEC-2021-0139
Dependency tree:
ansi_term 0.12.1
├── lscolors 0.12.0
│   └── fd-find 8.5.3
└── fd-find 8.5.3

Crate:     tempdir
Version:   0.3.7
Warning:   unmaintained
Title:     `tempdir` crate has been deprecated; use `tempfile` instead
Date:      2018-02-13
ID:        RUSTSEC-2018-0017
URL:       https://rustsec.org/advisories/RUSTSEC-2018-0017
Dependency tree:
tempdir 0.3.7
└── fd-find 8.5.3

error: 1 vulnerability found!
warning: 2 allowed warnings found

[tmccombs]

I looked into this a bit.

First the easy one: I made a PR to switch from using tempfile to tempdir.

For time:

time fixed that RUSTSEC issue by making it so that on UNIX you will get an Err if it tries to get the local time (or local offset) when there is more than one thread.

Since we parse the local time string before we spawn any threads, this is mostly not a problem. Except that by default cargo runs tests in multiple threads, so one of our tests fails due to not being able to get the offset. I think I might be able to work around this though. Alternatively, we could continue using chrono, but stop using the default features, so we don't include the time dependency.

For ansi_term we would need to remove that from the upstream lscolors crate (which @sharkdp also maintains). I'm not sure what the best alternative to swtich to would be here. Maybe termcolor since that is already used by clap? Although I'm not sure if that has everything needed to replace ansi_term.

[tavianator]

There is nu_ansi_term that lscolors also supports