Implement TrialResult JSON serialization

[kevinsung]

This is an alternative to #2561 that works for qudits. As mentioned there, it is 8x less space efficient for qubits. We could have a special case to handle binary-valued measurements but maybe we want to be consistent and keep the code simple? I don't know. I should add more test cases but I just wanted to put this out to get feedback on.

[kevinsung]

Okay I've added a special case for binary-valued arrays. Also, note that this serialization method does not work when the measurement values are Python ints or arbitrary Python objects, since it uses numpy.save with "allow_pickle" set to False to ensure portability. The measurement values must be fixed-width numerical values. I don't think this is a practically relevant limitation. @Strilanc PTAL.

[Strilanc]

After looking this over, I think we should do something slightly different.

Instead of special casing the numpy array storage for this single method, we should include np.ndarray as one of our supported types and do all the fancy bitpacking stuff there. That way the benefit will be shared across the library.

This does have some backwards compatibility constraints. We need to continue supporting numpy arrays serialized as a raw list.

[Strilanc]

Rough list of things to be done:

1. Around like ~260 of json.py, add a case for isinstance(o, np.ndarray). It should call into a helper method that does possibly different things for the different dtypes.

2. In the big dictionary at the start of json.py, include an np.ndarray entry associated with a method that supports deserializing the bitpacked stuff but also the raw lists.

3. Add test files to json_test_data directory.

[kevinsung]

@Strilanc I'm having trouble with (2.). When the JSON deserializer sees a list it will automatically treat it as such; how do you cause it to trigger specialized code upon encountering a generic list that it has no way of knowing originated as a Numpy array?

[kevinsung]

(2.) may be possible by implementing our own JSONDecoder subclass...

[kevinsung]

But still the issue remains which is that the decoder has no way of knowing whether the list originated from a Numpy array or not.

[mpharrigan]

Instead of special casing the numpy array storage for this single method, we should include np.ndarray as one of our supported types and do all the fancy bitpacking stuff there.

I'm not sure I agree with this. Decaying to lists by default plays nicest with json. There's automatic interop with other languages and it's eyeball-able. For special cases where you've got a massive ol' chunk of data (particularly bitstrings or wavefunctions or things which aren't eye-ballable anyways) they can be treated as a binary blob

[Strilanc]

Alright, it's fine to just do the one case. We can target specific ones when we run into them, and extract common methods when needed.

[kevinsung]

@Strilanc so we're good to leave this PR as is then?