ANDROID: sched/fair: remove order from CPU selection

find_best_target is currently split into code handling latency sensitive
tasks and code handling non-latency sensitive tasks based on the value
of the prefer_idle flag.
Another differentiation is done for boosted tasks, preferring to start
with higher-capacity CPU when boosted, and with more efficient CPUs when
not boosted. This additional differentiation is obtained by imposing an
order when considering CPUs for selection. This order is determined in
typical big.LITTLE systems by the start point (the CPU with the maximum
or minimum capacity) and by the order of big and little CPU groups
provided in the sched domain hierarchy.

However, it's not guaranteed that the sched domain hierarchy will give
us a sorted list of CPU groups based on their maximum capacities when
dealing with systems with more than 2 capacity groups.
For example, if we consider a system with three groups of CPUs (LITTLEs,
mediums, bigs), the sched domain hierarchy might provide the following
scheduling groups ordering for a prefer_idle-boosted task:
   big CPUs -> LITTLE CPUs -> medium CPUs.
If the big CPUs are not idle, but there are a few LITTLEs and mediums
as idle CPUs, by returning the first idle CPU, we will be incorrectly
prefering a lower capacity CPU over a higher capacity CPU.

In order to eliminate this reliance on assuming sched groups are ordered
by capacity, let's:
1. Iterate though all candidate CPUs for all cases.
2. Minimise or maximise the capacity of the considered CPU, depending
on prefer_idle and boost information.

Taking in part each of the four possible cases we analyse the
implementation and impact of this solution:

1. prefer_idle and boosted
This type of tasks needs to favour the selection of a reserved idle CPU,
and thus we still start from the biggest CPU in the system, but we
iterate though all CPUs as to correctly handle the example above by
maximising the capacity of the idle CPU we select. When all CPUs are
active, we already iterate though all CPUs and we're able to maximise
spare capacity or minimise utilisation for the considered target or
backup CPU.

2. prefer_idle and !boosted
For these tasks we prefer the selection of a more energy efficient CPU
and therefore we start from the smallest CPUs in the system, but we
iterate through all the CPUs as to select the most energy efficient idle
CPU, implementation which mimics existing behaviour. When all CPUs are
active, we already iterate though all CPUs and we're able to
maximise spare capacity or minimise utilisation for the considered
target or backup CPU.

3. !prefer_idle and boosted and
4. !prefer_idle and !boosted
For these tasks we already iterate though all CPUs and we're able to
maximise the energy efficiency of the selected CPU.

Change-Id: I940399e22eff29453cba0e2ec52a03b17eec12ae
Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Reviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>