sched_ule: Recover previous nice and anti-starvation behaviors

Justification for this change is to avoid disturbing ULE's behavior too
much at this time. We however acknowledge that the effect of "nice"
values is extremely weak and will most probably change it going forward.

Tuning allows to mostly recover ULE's behavior prior to the switch to
a single 256-queue runqueue and the increase of the timesharing priority
levels' range.

After this change, in a series of test involving two long-running
processes with varying nice values competing for the same CPU, we
observe that used CPU time ratios of the highest priority process to
change by at most 1.15% and on average by 0.46% (absolute differences).
In relative differences, they change by at most 2% and on average by
0.78%.

In order to preserve these ratios, as the number of priority levels
alloted to timesharing have been raised from 136 to 168 (and the subsets
of them dedicated to either interactive or batch threads scaled
accordingly), we keep the ratio of levels reserved to handle nice values
to those reserved for CPU usage by applying a factor of 5/4 (which is
close to 168/136).

Time-based advance of the timesharing circular queue's head is ULE's
main fairness and anti-starvation mechanism. The higher number of
queues subject to the timesharing scheduling policy is now compensated
by allowing a greater increment of the head offset per tick. Because
there are now 109 queue levels dedicated to the timesharing scheduling
policy (in contrast with the 168 levels alloted to timesharing levels,
which include the former but also those dedicated to threads considered
interactive) whereas there previously were 64 ones (priorities spread
into a single, separate runqueue), we advance the circular queue's head
7/4 faster (a ratio close to 109/64).

While here, take into account 'cnt' as the number of ticks when
advancing the circular queue's head. This fix depends on the other code
changes enabling incrementation by more than one.

MFC after: 1 month
Event: Kitchener-Waterloo Hackathon 202506
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46566