ConflictDetector: kill both tasks

[smurfix]

It's not always obvious which task is the "bad guy" when a conflict occurs. If the "legitimate" task crashes and the buggy one, i.e. the one that forgot to take the lock, does not, the backtrace is not helpful.

Thus, kill them both.

[codecov[bot]]

Codecov Report

Merging #2540 (6adbaf0) into master (82533e8) will decrease coverage by 1.07%. The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2540      +/-   ##
==========================================
- Coverage   93.50%   92.44%   -1.07%     
==========================================
  Files         118      118              
  Lines       16335    16340       +5     
  Branches     3156     3157       +1     
==========================================
- Hits        15274    15105     -169     
- Misses        955     1105     +150     
- Partials      106      130      +24     

Impacted Files	Coverage Δ
trio/_util.py	94.91% <100.00%> (+0.22%)	:arrow_up:
trio/testing/_check_streams.py	100.00% <100.00%> (ø)
trio/tests/test_signals.py	100.00% <100.00%> (ø)
trio/tests/test_ssl.py	99.86% <100.00%> (ø)
trio/tests/test_testing.py	99.53% <100.00%> (ø)
trio/tests/test_util.py	100.00% <100.00%> (ø)
trio/_subprocess_platform/kqueue.py	0.00% <0.00%> (-100.00%)	:arrow_down:
trio/_core/_io_kqueue.py	0.80% <0.00%> (-83.88%)	:arrow_down:
trio/lowlevel.py	58.33% <0.00%> (-16.67%)	:arrow_down:
trio/_core/__init__.py	75.00% <0.00%> (-12.50%)	:arrow_down:
... and 14 more

[smurfix]

These codecov results seem rather spurious.

[oremanj]

This is a breaking change. Previously, if you wanted to see if some other task was waiting on an FD, you could try to wait on it and catch BusyResourceError. I have used this pattern to implement "make sure someone is waiting" on multiplexed interfaces (such as inotify) without a system task. I would be frustrated if we broke that.