Add a defaultReapInterval setting to active swingset configurations

[FUDCo]

Issue #4160 set out to address the performance impact of Bring Out Your Dead, in particular to figure out what the optimal frequency should be set to. @arirubinstein ran a bunch of benchmarks that suggest that a value around 1000 was about right. What remained was to actually translate this into practice, which this PR does.

There remained an open question whether the appropriate way to set this value was to insert parameter settings into the configuration files for the swingsets that would be impacted operationally or to adjust the default value that's coded into SwingSet itself. After discussion, @warner and I concluded that the correct answer is to set it in the config files. There are two main reasons for this, one minor and one more significant.

The minor reason is that many, many tests implicitly depend on the existing default (which is 1) for the reference behavior that they check for. Updating the default in the kernel code would require all those tests to be identified and changed to set the parameter themselves. However, convenience of test maintenance is not by itself a very compelling reason for this course.

The more significant reason is that this parameter is one of the settings that can be dynamically adjusted at run time by governance action and it impacts the consensus behavior of the chain, so it is appropriate that it be managed explicitly rather than simply accepting whatever default the current SwingSet implementation happens to cough up. In particular, if we determine at a later time that a different source default is better, it would be best if the operational setting did not derive from something hardcoded into the kernel and thus cause on-chain behavior to alter just because of a perhaps unrelated kernel update. In other words, even if this PR changed the default in the kernel source code, we would still want to put it into the operational swingset configurations anyway. But since we are putting it there, in operational terms the kernel default is irrelevant and so it might as well stay with the value that's convenient.

Closes #4160

Note to @dckc: @warner and I guessed that you're the right person to pass judgement on this so you are tagged as the reviewer, but if you think otherwise, please feel free to decline it or kick it over to whoever you think might be more appropriate.

[dckc]

looks like a reasonable approach.

I haven't done anything to confirm that it works; I suppose we'll find out soon enough.