Document counter-intuitive round-robin cache_dir selection bias; decrease it.

Many squid.confs have at least two groups of cache_dir lines. For example,
rare "large" objects go to larger/slower HDDs while popular "small" objects go
to smaller/fast SSDs:

    # HDDs
    cache_dir rock /hdd1 ... min-size=large
    cache_dir rock /hdd2 ... min-size=large
    cache_dir rock /hdd3 ... min-size=large
    # SSDs
    cache_dir rock /ssd1 ... max-size=large-1
    cache_dir rock /ssd2 ... max-size=large-1
    cache_dir rock /ssd3 ... max-size=large-1
    # rock store does not support least-load yet
    store_dir_select_algorithm round-robin

Since round-robin selects the first suitable disk during a sequential scan,
the probability of /hdd1 (/ssd1) selection is higher than other HDDs (SSDs).
Consider a large object that needs an HDD: /hdd1 is selected whenever scan
starts at /ssd1, /ssd2, /ssd3, and /hdd1 while /hdd2 is selected only when the
scan starts at /hdd2 itself! Documentation now warns against the above
cache_dir configuration approach and suggests to interleave cache_dirs:

    cache_dir rock /hdd1 ... min-size=large
    cache_dir rock /ssd1 ... max-size=large-1
    cache_dir rock /hdd2 ... min-size=large
    cache_dir rock /ssd2 ... max-size=large-1
    cache_dir rock /hdd3 ... min-size=large
    cache_dir rock /ssd3 ... max-size=large-1
    store_dir_select_algorithm round-robin

Squid's historic implementation of round-robin made its natural bias even
worse because it made the starting point of the sequential scan to be the last
selected dir. In the first configuration example above, it boosted the
probability that the scan will start at one of the SSDs because smaller
objects are more popular and, hence, their dirs are selected more often.  With
the starting point usually at an SSD, even more _large_ objects were sent to
/hdd1 compared to other HDDs! The code change avoids this artificial boost
(but the cache_dir lines should still be interleaved to avoid the natural
round-robin bias discussed earlier).