Hash rate refactoring & JSON support

[logiclrd]

Added support for a separate endpoint returning hashrate stats in JSON format:

• Factored the hashrate computation logic out of userstats.php into new file hashrate.php.
• Added new endpoint hashrate-json.php that uses hashrate.php in much the same way as userstats.php, but outputs only the hashrate table information formatted as JSON.

The refactored code used to assign to local variables $u16avghash, $u16shares, $u2avghash, $u2shares and then an array $my_shares with entries for 256- and 128-second intervals. Its updated form consolidates all of these down to a single object, and that object is structured as a set of maps. Each map has the same set of properties, so that they can be processed identically by a caller. A typical object looks like this (once encoded in JSON):

{
  "intervals":[10800,1350,256,128],
  "10800":{"interval":10800,"interval_name":"3 hours","hashrate":819225243.4963,"shares":2060},
  "1350":{"interval":1350,"interval_name":"22.5 minutes","hashrate":814453057.61185,"shares":256},
  "256":{"interval":256,"interval_name":"256 seconds","hashrate":805306368,"shares":48},
  "128":{"interval":128,"interval_name":"128 seconds","hashrate":637534208,"shares":19}
}

This object provides everything that userstats.php needs to generate its table, and is also exactly the data that I want to be able to export as JSON.

[logiclrd]

Oh, and the structure explicitly lists intervals to guarantee a specific ordering of them in the grid. Technically, PHP's maps are already ordered, but a caller decoding the JSON in some other language might end up putting the data into a structure that does not guarantee order.

[wizkid057]

Merged. Thanks for the contribution!