change cpuinfo_cur_freq to scaling_cur_freq because of access problems on wheezy

On Debian Wheezy `procstats.py` was failing to run.
Investigation showed that required file `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq` was not readable by `tcollector` user.

The filetree looks like this on `Debian 3.2.57-3+deb7u2 x86_64 GNU/Linux`:
```
# ls -l /sys/devices/system/cpu/cpu0/cpufreq/
-r--r--r-- 1 root root 4096 Oct  7 10:54 affected_cpus
-r--r--r-- 1 root root 4096 Oct  7 10:54 bios_limit
-r-------- 1 root root 4096 Oct  2 17:29 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Oct  2 17:29 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Oct  2 17:29 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Oct  7 10:54 cpuinfo_transition_latency
-r--r--r-- 1 root root 4096 Oct  7 10:54 related_cpus
-r--r--r-- 1 root root 4096 Oct  7 10:54 scaling_available_frequencies
-r--r--r-- 1 root root 4096 Oct  7 10:54 scaling_available_governors
-r--r--r-- 1 root root 4096 Oct  7 10:54 scaling_cur_freq
-r--r--r-- 1 root root 4096 Oct  7 10:54 scaling_driver
-rw-r--r-- 1 root root 4096 Oct  7 10:54 scaling_governor
-rw-r--r-- 1 root root 4096 Oct  7 10:54 scaling_max_freq
-rw-r--r-- 1 root root 4096 Oct  7 10:54 scaling_min_freq
-rw-r--r-- 1 root root 4096 Oct  7 10:54 scaling_setspeed
```

The reason for that can be found in following mailing list post:
http://www.spinics.net/lists/cpufreq/msg02104.html

As stated there the change of permissions was made according to possible security issues.
They recommend to use `scaling_cur_freq` instead: "scaling_cur_freq differs from
cpuinfo_cur_freq _only_ if something is broken."