sched/rt: Support multi-criterion fitness search for lowest_rq

We have multiple criterion that need to be taken into account when
searching for best fitting lowest_irq.

On big.LITTLE systems, when uclamp is used, we use
rt_task_fits_capacity() to enforce going to a larger CPU if the task's
uclamp_min requested that. But we still would have fallen back to
priority based search if no fitting CPU was found.

There are reports now that severe thermal pressure could make the big
CPUs throttled to the point where they are less performant than the
mediums (capacity inversion).

To cater for that, we need to take into account thermal pressure
reducing the capacity of the CPU in the fitness search.

Note that this could introduce another set of problems if not careful.

For instance if an RT task has uclamp_min = 1024, a small amount of
thermal pressure could mean no CPU will fit this task; which means the
hint will become less effective. The big CPU still provides the max
performance level (which is what uclamp_min=1024 is asking for) so we
still better place it there even if thermal conditions mean we lost some
performance.

This corner case can happen at any boundary conditions for littles,
mediums or bigs. For example if an RT task has uclamp_min
= capacity_orig_of(medium_cpu), then any small thermal pressure will
prevent placing it there and force it to big CPUs instead. Which is not
the desired outcome if no big CPU is available. We should still fallback
to the medium CPU in this case.

This dictates a more complex search method to enable multi-level
fallback.

That is:

	1. If rt_task_fits_capacity_thermal() returns true, we should
	   pick this lowest_mask.
	2. If (1) failed for all priorities, we should fallback to
	   rt_task_fits_capacity() lowest_mask if it found any.
	3. If (1) and (2) failed, we should fallback to the lowest_mask
	   based on lowest priority rq as usual.

We teach cpupri_find_fitness() to do a multi-level search in a single
loop. This is at the cost of allocating more cpumasks for each fitness
criteria/level.

At the moment, the only users are heterogeneous systems which have low
CPU count and this should not lead to a big waste of memory.

The priority of fitness_fn is highest starting from 0.

Signed-off-by: Qais Yousef <qais.yousef@arm.com>