Make the number of "camera scans" constant in the philosophers benchmark

[lbulej]

This includes two related changes and one extra bit.

The first reduces the duration of the transaction building the "image of the scene". Previously the image was being built inside the transaction, making the transaction last unnecessarily longer. Now we only take a snapshot of the state within the transaction and build the image outside the transaction to avoid blocking philosopher threads.

The second change makes the number of scans constant for a given workload. Previously, camera scans were triggered in reference to wall clock time, resulting in variable number of scans during each repetition. Now the camera scans are requested based on thread progress. To keep the number of camera scans constant, the requests are counted to avoid potential loss of wake-ups when the rate of progress increases (due to reduced contention towards the end of the workload).

These two changes should alleviate the banding in the operation durations (#202), but probably not entirely, because there simply is a thread that periodically blocks all threads for a while.

The extra bit is inclusion of the number of camera scans in the validation.

Below are plots from simple measurements I collected from 15 runs (150 repetitions each) using JDK 11 (default settings) on 8 cores of Xeon E5-2697A v4:

• the split_scan variant corresponds to commit baf1431
• the const_scan_lbq variant corresponds to commit c4144c3 (scan requests queued using LinkedBlockingQueue)
• the const_scan_stm variant corresponds to commit 169cbe3 (scan requests "queued" using STM transactions)

At the moment, this is stacked on top of #444, #445, and #446.