[drcachesim] trim trace to avoid staggered attach and detach partial-thread anomalies at ends of trace

Xref #1729 (closed)

Due to the asynchronous nature of stopping all the threads on detach, some may run further and produce more data than we'd like for a bursty trace. I already added a new option -max_trace_size to put a cap on the per-thread trace size, but we probably also want a way to precisely throw out data past the detach timestamp.

On the burst-threads test, without the -max_trace_size cap, the secondary threads produce surprisingly large traces: 65MB, when the start/stop thread only ran 4 iters of its loop. It may be worth investigating further to ensure nothing is going wrong there: is it really just a few hundred more iters that adds up to 65MB??