fix reduce type constraints on JSON materializer

[zilto]

This issue is a follow-up on #690

Before, the JSON Loader&Saver would only support dict type objects. However, the JSON format specs are more flexible. We then introduced support for List[dict].

However, it seems reasonable to support more generally list (of str, int, None, etc.). By making it more flexible, we delegate to the underlying json Python library to surface "not json-serializable" errors to the user.

Changes

• changed supported types from List[dict] to list
• adjusted tests accordingly

How I tested this

• test succeed locally

Notes

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[elijahbenizzy]

OK, I think this should be 100% backwards compatible. Only issue is if the original json gets passed over to someone's custom json one, but that should work anyway (as we'll do the same thing). Might want to add a note on this.

Basically, we evaluate on type + order -- they're supposed to add their custom one in last, as it is done in reverse order. Given that, I don't think this will break anything.