Fix Test_issue80 on Go 1.8

[dsnet]

An upstream change (http://golang.org/cl/30371) makes the Go encoder
to be more compliant with the ES6 standard. Ironically, this change
causes Test_issue80 to fail on the larger number ranges.

To make this test work on both Go 1.7 and Go 1.8, we delete the larger
value tests, which are arguably locking in the wrong behavior.

Updates #80

[dsnet]

The JS engine in Chrome produces the following output for the given tests:

"[1401868959,14018689591,140186895901,1401868959001,14018689590001,140186895900001,1401868959000001,1401868959000001.5,14018689590000000,140186895900000000,1401868959000000000,14018689590000000000,140186895900000000000,140186895900000000000]"

This actually more closely matches to what Go 1.8 produces:

"[1401868959,14018689591,140186895901,1401868959001,14018689590001,140186895900001,1401868959000001,1401868959000001.5,14018689590000001,140186895900000001,1401868959000000001,14018689590000000000,140186895900000000000,140186895900000000000]"

And very different from the values locked in by the test (which is the Go 1.7 behavior).

"[1401868959,14018689591,140186895901,1401868959001,14018689590001,140186895900001,1401868959000001,1.4018689590000015e+15,14018689590000001,140186895900000001,1401868959000000001,1.401868959e+19,1.401868959e+20,1.401868959e+20]"

[dsnet]

\cc @deoxxa

[stevenh]

Should the old test values be made pre 1.8 only?

[dsnet]

I don't think so for the following reasons:

• It's more complexity split the test into a <Go1.8 and >=Go1.8 versions.
• The values being removed do not match the results of what Chrome's JS engine prints out. In that sense, they are "wrong".
• Issue json.stringify printing JS integers using exponential notation #80 was not about correctness, but convenience.