U64 as displayed in the UI are wrong.

As spotted in #2011.

U64 field are very nice for users indexing ids.
They can be a nicer solution than strings, for instance if we do grouping and the number of distinct values does not justify dicitonary encoding.

Javascript will deserialize their JSON value as a javascript Number, which has a limited precision.
The number as displayed in the UI will hence be erroneous.

This limitation is not really a JSON issue (AFAIK JSON does not
restrict the range of integer values), but is shared by many other programming language.

I am not entirely sure what we should do here tbh. :)

We also probably support string as an input for u64.

On serialize, a common solution to this problem is to add a string version of int fields.

"id": 23423432432424324,
"id_str": "23423432432424324"

But then we could have some collision problems.
We could add a serialization option to serializes all ints as a string.

Start by reviewing the U64 JSON serialization and the UI deserialization behavior described here, then compare the related discussion in issue #2011. Clarify whether string input is supported and which serialization representation should be authoritative. Done means the chosen approach preserves full U64 values in the UI without collisions.