Re-introduce the 'blocking' kwargs to at-sync.

[maleadt]

This can be used to force a blocking, but low-latency synchronization, e.g., when benchmarking code that uses a single task.

Marked as draft, because I don't want to merge this before I'm convinced that #2059 recovered the performance we lost.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +29.75% 🎉

Comparison is base (ac1bc29) 29.55% compared to head (8e11d6f) 59.30%.

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #2060       +/-   ##
===========================================
+ Coverage   29.55%   59.30%   +29.75%     
===========================================
  Files         157      152        -5     
  Lines       13834    13311      -523     
===========================================
+ Hits         4088     7894     +3806     
+ Misses       9746     5417     -4329     

Files Changed	Coverage Δ
lib/cudadrv/synchronization.jl	96.06% <100.00%> (+33.85%)	⬆️
src/utilities.jl	75.70% <100.00%> (+6.83%)	⬆️

... and 110 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maleadt]

Actually, I shouldn't be worried merging this: It only changes how we synchronize the outer CUDA.@sync, not what's done within. So when benchmarking, e.g., a memory copy, or an operation that synchronizes, we'd still be benchmarking the nonblocking sync within. So let's just add a couple of synchronization benchmarks.