Cycles-X: Add hysteresis to resolution divider algorithm

Adds hysteresis to the resolution divider algorithm to avoid having the resolution bounce around when on the boundary of two resolutions.

Reviewed By: brecht, leesonw

Differential Revision: https://developer.blender.org/D12385

Fix performance decrease with Scrambling Distance on

With the current code in master, scrambling distance is enabled on non-hardware accelerated ray tracing devices see a measurable performance decrease when compared scrambling distance on vs off. From testing, this performance decrease comes from the large tile sizes scheduled in `tile.cpp`.

This patch attempts to address the performance decrease by using different algorithms to calculate the tile size for devices with hardware accelerated ray traversal and devices without. Large tile sizes for hardware accelerated devices and small tile sizes for others.

Most of this code is based on proposals from @brecht and @leesonw

Reviewed By: brecht, leesonw

Differential Revision: https://developer.blender.org/D13042

Cycles: Update UI for Scrambling Distance Patch

The current UI for the Scramble Distance patch is grayed out
depending on different settings that are enabled. However it
didn't make much sense to me so I have updated when the UI is
grayed out to hopefully make more sense to the end user.

Differential Revision: https://developer.blender.org/D12963

Fix incorrect auto minimum samples for adaptive sampling

The comment did not match the implementation.

Differential Revision: https://developer.blender.org/D12561

Cycles-X: Fix incorrect performance calculation at certain navigation resolutions

During viewport navigation the algorithm that calculates the resolution divider assumes that the at every resolution division the sample count will be 4. This is not true for cases where the resolution division is equal to `2 * pixel_size` and `pixel_size`. In those cases the sample count is 1. As a result the algorithm assumes `2 * pixel_size` and `pixel_size` are too expensive in a lot of cases and thus doesn't use it.

This patch addresses this issue by informing the algorithm of changes in sample counts between resolution divisions meaning it can more properly gauge the performance of various resolution divisions. As a result the algorithm is more likely to pick the correct resolution divider when performance of the scene is in the range that `2 * pixel_size` and `pixel_size` are viable options all while keeping the performance target at 30fps like before.

Along with this patch the sample count while the resolution divider is equal to `2 * pixel_size` has been increased from 1 sample per pixel to 2 samples per pixel. Without an increase to this value there are some negative side effects. I have chosen the value of 2 and not 4 because this values means at a resolution divider of `2 * pixel_size` the rendering is still cheaper than a resolution divider of `pixel_size`.

Differential Revision: https://developer.blender.org/D12367

Cycles-X: Change viewport update system to be time based rather than sample based on fast devices

The viewport update speed when rendering with infinite samples has been changed to work based primarily on time since render start rather than sample count.

This change has been made because if you have a device fast enough to exceed 32 samples in 0.1 seconds, then the next viewport update you'll observe is 2 seconds after `render start` which can be annoying for anyone wishing to quickly iterate on fine details as `render start` is usually a 1 sample per pixel image meaning fine detail is lost in noise or overly blurred by a denoiser.

This change was made possible with help from Will Rusthon (a friend) and Blender developers.

Here is an example video of the issue (some of the "viewport changes" you see are due to compression artifacts to keep the video small):
{F10290321}

And here is my fix tested (the second demo with the caustics is there to show that the viewport updates reduce as time goes on. It's easier to see in the caustics scene due to the fireflies. This is important because reduced viewpoint updates means faster ray tracing. The difference is that with this patch the slow viewport update (once every 2 seconds) has been moved to after rendering for 8 seconds rather than occurring at 32 samples which could happen really quickly with simplistic scenes. Also the denoiser stopping at the end of the video has been fixed and is currently in the patch available for review):
{F10290508}

Reviewed By: sergey, leesonw

Differential Revision: https://developer.blender.org/D12265

Fix T90804: small grammatical error in noise threshold description

Differential Revision: https://developer.blender.org/D12277