Let JavaScript parse JSON and write JSON ...

[jdunkerley]

Pull Request Description

Use JavaScript to parse and serialise to JSON. Parses to native Enso object.

• .to_json now returns a Text of the JSON.
• Json methods now parse, stringify and from_pairs.
• New JSON_Object representing a JavaScript Object.
• .to_js_object allows for types to custom serialize. Returning a JS_Object.
• Default JSON format for Atom now has a type and constructor property (or method to call for as needed to deserialise).
• Removed .into support for now.
• Added JSON File Format and SPI to allow Data.read to work.
• Added Data.fetch API for easy Web download.
• Default visualization for JS Object trunctes, and made Vector default truncate children too.

Fixes defect where types with no constructor crashed on to_json (e.g. Matching_Mode.Last.to_json.
Adjusted default visualisation for Vector, so it doesn't serialise an array of arrays forever.
Likewise, JS_Object default visualisation is truncated to a small subset.

New convention:

• .get returns Nothing if a key or index is not present. Takes an other argument allowing control of default.
• .at error if key or index is not present.
• Nothing gains a get method allowing for easy propagation.

Important Notes

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide build and ./run ide watch.

[radeusgd]

first batch of comments

[radeusgd]

Good catch that these need to be accounted for. Does it work though? I'm not sure how it plays with self tbh.

Regardless if it works (well if not - then even more so) - this really feels weird to look at - ofc not something to do for now, but I think we should figure out how to distinguish defining such methods for the instance and their static variants. My intuition would see them as rather separate definitions, instead of having to do such matches.

@hubertp @kustosz as you've been close to the statics - any thoughts? Is it even possible to have a static and non-static variant of a method with same name? I'm worried it may conflict with the Type.instance_method instance_ref args call pattern, so I'm not sure if it is even possible. Still seems that from the 'user' (in this context: library developer) perspective, we need to be able to define some methods both on instances and on the type itself.

[jdunkerley]

Yes, these work. I agree that it is not a great pattern but is needed in the current set up.

[radeusgd]

Why is the constructor a method name? Seems surprising.
Do we even need the constructor here? I guess it makes sense to be consistent with Atom serialization, but we put a method name instead of true constructor so we are not truly consistent anyway.

[jdunkerley]

The idea is to make it, so we had the information to deserialise.
Originally had fully qualified type names but decided against it for this version.

[hubertp]

Why is "" still needed?

[jdunkerley]

JavaScript strings cause an issue with the visualisation. The "" + makes it an Enso Text and then it works,