i#6636: Add randomized schedule feature

[derekbruening]

Adds a new scheduler option randomize_next_input and corresponding launcher option -sched_randomize. When enabled, priorities and timestamps and FIFO ordering are ignored and instead a random next element from the ready queue is selected. This will be useful for schedule sensitivity studies.

Adds a unit test.

Tested manually end-to-end as well:

  $ for ((i=0; i<10; ++i)); do bin64/drrun -t drcachesim -simulator_type schedule_stats -core_sharded -indir ../src/clients/drcachesim/tests/drmemtrace.threadsig.x64.tracedir/ -cores 2 -sched_randomize 2>&1 | grep schedule; done
  Core #0 schedule: HEFBF_
  Core #1 schedule: GCDFA
  Core #0 schedule: GDBH
  Core #1 schedule: CFAFEF__
  Core #0 schedule: GDBF__
  Core #1 schedule: EFCFAH
  Core #0 schedule: BHFDF__
  Core #1 schedule: EGFAC
  Core #0 schedule: HAFEF__
  Core #1 schedule: GDCFB
  Core #0 schedule: ABFGF__
  Core #1 schedule: CEDFH
  Core #0 schedule: HDBF_F_F__
  Core #1 schedule: ECGA
  Core #0 schedule: HDEFA
  Core #1 schedule: CBFGF__
  Core #0 schedule: FHGFCF_
  Core #1 schedule: DEAB
  Core #0 schedule: EFABF_
  Core #1 schedule: GCDFH

Fixes #6636

[derekbruening]

Hmm, every schedule is the same on Windows. The randomizer is seeded from the clock. Is the clock virtualization that bad on these runner VM's?

[derekbruening]

Hmm, every schedule is the same on Windows. The randomizer is seeded from the clock. Is the clock virtualization that bad on these runner VM's?

It looks like GetSystemTime just has poor granularity: it returns the same time throughout the whole test. QueryPerformanceCounter is much better and makes the test pass. But, there are several other uses of GetSystemTime so maybe a separate PR should update them all and then this one can merge it in. So I think this can be reviewed as-is; won't be merged until that Windows change is made separately and this becomes green.