PM / devfreq: Introduce a sysfs lock

Currently, concurrent writes to sysfs entries leave the	possibility
for race conditions within the devfreq framework.  For example,
concurrently executing max_freq_store and governor_store can result
in attempting to perform an update_devfreq() before the new governor's
start handler can be executed.

A more concrete case is a race between polling_interval_store and
governor_store.  Because no lock is used after calling into the event
handler of the old governor and there's nothing preventing work from
being queued after the monitor is stopped, it's possible to
accidentally cause delayed work to be queued on the governor being
switched to.  This can be seen if you create two threads, one which
changes a device's governor between simple_ondemand and performance,
and one which changes its polling interval between 45 and 50.

All of these races can be addressed with the introduction of a lock
that prevents sysfs operations from interleaving in this fashion.

Change-Id: Ia6887dcb2d69dc2576837a6c09fed55a28943abc
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
Signed-off-by: Rama Aparna Mallavarapu <aparnam@codeaurora.org>