[RFC][DON'T MERGE] PM: EM: Add support for runtime modification of Energy Model values

====================================================================
Important Note:
This is an experimental patch aiming to discuss/test the idea of
runtime modifiable EM. It tries to address the impact of static power
(leakage) change in time due to different temperature of the chip.
The purpose of sharing this patch is to get feedback from Vendors
making the real SoCs, and gather details such as:
- does it address the problem
- doesn't contain design restrictions (such as values scale, math
model),
- performs fast&smooth (lack of unacceptable delays in runtime updates)
- fits into the right running context of the EM modifier (e.g. thermal
governor, driver IRQ handler, etc)
- allows for optimizations and/or differentiation of the power vs.
  performance policy
After positive feedback and results the goal is to share this work
on the Linux Kernel Mailing List (together with justification) to
make it available in upstream/Android/production kernels.
====================================================================

The Energy Model (EM) holds performance state information in an array,
which is used directly by other subsystems. The values stored there
cannot be modified at runtime. There is a need to modify that data to
better reflect the energy efficiency of the CPUs, which might change due to
increased static power (leakage) at higher temperature. Thus, extend EM
with a new feature which allows to safely modify power values at runtime.

The new feature enables drivers or frameworks to adjust the EM power
(and cost) values based on dynamically changing environment. The newly
adjusted EM values would be used by the Energy Aware Scheduler (EAS) for
better task placement.

This is a powerful feature and should be used with full awareness of the
impact. It enables experimenting with new ideas like optimise the usage of
certain types of CPUs in a heterogeneous systems to avoid using most power
consuming CPUs in some scenarios until all others are fully loaded.

The new EM structure doesn't put any restriction for the power values,
and allows the modifier to store any value. There is no predefined math
model or formula that the power of each performance state must fit in
(there is only an upper limit for the values to not overflow results on
32bit machines).
This also has consequences for consumers of the EM data, such as thermal
framework, to not use run-time modifiable EM information. Thus, there are
two tables in the EM:
- non-modifiable (setup at boot, reliable and untouched data)
- run-time modifiable (for optimizations of the EAS).

The EM maintains the original power information not touched from the first
setup. All EM clients which use 'power' values must use the non-modifiable
EM data (EAS uses 'cost' values).

Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>