Create TTL map with time wheel architecture

This change adds a DashMap-like struct which has a background tasks to clean
up entries that have outlived a configurable TTL.

This data structure is added so it can be used in the `ArrowFlightEndpoint`, where it's
possible for `ExecutionStages` to be orphaned due to errors. This change adds the ability to
clean up tasks async.

The implementation is simliar to https://github.com/moka-rs/moka, which also uses
time wheels. Benchmarks show that this implementation has less overhead per operation
than moka (see results #99).
```
=== TTLMap Moka Benchmark ===
Tasks: 100000
Total time: 162.53ms
Average latency: 45 μs per operation
Throughput: 615257.30 ops/sec

=== TTLMap Lock Contention Benchmark ===
Tasks: 100000
Total time: 137.07ms
Average latency: 985 ns per operation
Entries remaining: 0
DashMap Lock contention time: 21ms
Accounting time: 47ms
```

There's also an implementation in #92, which
has the worst performance by far.
```
Tasks: 100000
Total time: 105.65ms
Average latency: 20453 μs per operation
Entries remaining: 0
DashMap Lock contention time: 23ms
Mutex Lock contention time: 2045251ms
```

Informs: #90

Author: jayshrivastava

src/common/mod.rs

@@ -1 +1,2 @@
+pub mod ttl_map;
 pub mod util;