Return of the threaded detection

[MarcMush]

with #325, the difference in performance with the safe_lock is much more noticeable compared to #322 (x4-5 on my machine)

this stores only the starting thread instead of a vector of all used threads (which is basically the same)

I can't see a repeatable difference between disabling the lock and letting in detect but both are still possible with this

Performance results from runtest.jl: (these numbers vary quite a lot between each run)

Performance results:
without progress:      1.23 ns/it
with no lock:          9.23 ns/it
with no printing:      8.85 ns/it
with disabled:         2.60 ns/it
with lock:            41.06 ns/it
with automatic lock:   9.02 ns/it
with lock, disabled:  32.18 ns/it
with force:            0.20 ms/it

Threaded performance results: (4 threads)
without progress:     64.75 ns/it
with automatic lock:   0.23 μs/it
with forced lock:      0.23 μs/it
with no printing:      0.24 μs/it
with disabled:         0.20 μs/it
with force:            0.25 ms/it

[MarcMush]

I'm open to other suggestions

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.78%. Comparing base (807496a) to head (f667095). Report is 19 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #328      +/-   ##
==========================================
+ Coverage   93.48%   96.78%   +3.30%     
==========================================
  Files           1        1              
  Lines         399      560     +161     
==========================================
+ Hits          373      542     +169     
+ Misses         26       18       -8     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.