Resolved bug that affected machines with non US Locales.

[ajcerejeira]

I was getting the following error, due to my machine being non US locale, so the values appeared with a comma instead of a dot:

0,000000#11913,476974#23490,014404
Exception in thread "main" java.lang.NumberFormatException: For input string: "0,000000"
	at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
	at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
	at java.lang.Double.parseDouble(Double.java:538)
	at EnergyCheckUtils.getEnergyStats(EnergyCheckUtils.java:49)
	at EnergyCheckUtils.main(EnergyCheckUtils.java:76)

The method getEnergyStats when calls Double.parseDouble fails because it expects the numbers to be formatted with a '.' instead of ','.
With the usage of NumberFormat it now uses the default System Locale, avoiding this problem.

Example output:

0,000000#13959,228394#27346,080170
0,000000#13966,696732#27378,764664
Power consumption of dram: 0.0 power consumption of cpu: 0.7468338000000585 power consumption of package: 3.268449399999736

[kliu20]

Thank you for the PR. Since this library is heavily used in some groups that are picky for the performance. It could be invoked thousands of times in a short period of time. I checked the implementation of NumberFormat class, The change would add some more overhead for the API since the branches, synchronized blocks (non-parallel program with synchronized block can be the overhead as well) and object creation operations. Since it's not the common case, compared with cost and benefit, we think we'd better to keep the original implementation. Thank you for the efforts!