msm: hotplug: Optimize latencies

Before this patch it took the algorithm too long to
react on sudden load spikes, although only noticable
in benchmarks. We would cycle 5-6 times until the
buffer average was finally high enough to trigger a
new target.  Improve latencies by instantly onlining
all cpus if current load on any cpu is above a certain
threshold.

fast_lane_load should not be higher than 78 as load
per cpu won't be above this value in our metric.

First cycle in hackbench
Before: 1.253sec
After: 0.796sec

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
msm: hotplug: Refactor load calculation

* Move core load calculations to this file and optimize.
* Calculate load based on current policy->max, not cpuinfo.max_freq
  which explains the strange 78% maximum load value before.
* Recalculate thresholds and fast_lane_load accordingly.
* Cleanup some ambiguous namings and other minor stuff.
* EXPORT_SYMBOL_* is useless for static functions.

Conflicts:
	arch/arm/mach-msm/msm_rq_stats.c
msm: hotplug: Allow to disable the circular stats buffer

This option reduces latency a tiny bit more.
msm: hotplug: Simplify store_history_size()
msm: hotplug: Underp input checks

Kids, don't drink and drive.
msm: hotplug: On- and offline cpus only when enabled

I mean really, really enabled...
msm: hotplug: Remove the redundant iowait check
msm: hotplug: Readd suspend max cpus and frequency options

We had this ages ago.
msm: hotplug: Use load dependent update rates
msm: hotplug: Fix another derp
msm: hotplug: Update default fast_lane_load

A value of 99% load catches almost all spikes and keeps spurious
onlinings to an absolute minimum.

Replace all instances of cputime64_t by u64 (see upstream commit
72a4ce340a7ebf39e1c6fdc8f5feb4f974d6c635).
msm: hotplug: Add io_is_busy interface
msm: hotplug: Check down lock for lowest load cpu

As reported by neobuddy89.