Add TYPE_INTEGER64 type to base::Value.

Add TYPE_INTEGER64 type to base::Value.
BUG=none
TEST=none

[kkania, 2011-12-23 00:19:47]

This CL isn't for actual review yet. I would need to go through and fix some of
the clients. I just wanted to see if this approach was ok before going ahead.


Problem:
I need to send back, in JSON, an integer that represents milliseconds since the
unix epoch. A 32 bit int will overflow. This is an external spec I am adhering
to, so I can't just send back a string or double instead.


Solutions:
1) Store integers as int64 instead of int. Add TYPE_INTEGER64 and additional
methods for creating/setting int64s. Allow GetAsInteger64 to set a given int64*
whether it is TYPE_INTEGER or TYPE_INTEGER64. This is the approach I have chosen
for this CL. There are two common bugs that this may introduce for unaware
clients:
First, a client may mistakenly think that the double can still represent all
number values and not check for int64. The JSON parser defaults to int64 before
double.
Second, a client may write an int64 to JSON and later accidentally read it back
as an int32. This will work until the value is greater than what an int32 can
hold. In that case, it will be promoted to int64 and may break the client.

2) Store integers as int64 instead of int. Keep current integer value methods
and add additional 64 bit ones. For integer values methods that take a regular
int, check the int64 value is in bounds before downcasting. If it's out of
bounds, return false.

3) Just use a double and don't add int64. The problem with this is that
JSONWriter appends a ".0" to doubles with no fractional value to keep the type
information. This causes most JSON implementations to parse it as a double. Add
an option to JSONWriter to turn off this behavior. Even so, a 64-bit double
doesn't cover as many integers as an int64. This is ok for my case however. Add
a GetAsInteger64 method, which converts from a TYPE_INTEGER or TYPE_DOUBLE, if
possible.


Other solutions:
1) Store integers as int64 instead of int. Convert all the int methods to use
int64. Most clients would have to convert from int64 to int themselves.

2) Change the spec I am adhering to to accept doubles as well as int64. This is
not so difficult, but it seems adding int64 to value should be done eventually
anyways and might be helpful for other uses.

[Nico, 2011-12-23 00:24:40]

Hi,

I think this came up a few times on chromium-dev, here's one instance that I
found:
https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thr...

Usually, the conclusion is that javascript supports only doubles anyway, and
doubles have 53 bits of mantissa * 2^0, which is enough in practice. So can you
just use doubles for your use case?