List Item Type Coalescing

This extends from both #19 and #20. 19 was originally going to be both for this and the Less-String Writing, but these ended up feeling like separate issues, based on a common theme.

On par with making more object data structures accessibly writable, I think it could make sense to also coalesce array values to be a single primitive type, rather than throwing an error for it. Ideally, your data coming into NBTify should be NBT-spec compliant, but if not, I think it's fair for the data to coalesce into being spec-compliant.

This would leave the user to work with their data accordingly, and to fall back on type definitions, or manual error checking for the item types.

In writing that last sentence, the other side of my mind says that it also makes sense to keep the error, as this feels similar to the recursive object data structure error that JSON.stringify() will throw if it encounters an object with that being the case. Maybe the Less-Strict Writing idea (#20) should only apply to objects, and maybe arrays should still be strict.

Gonna experiment with all three of these ideas, and see how they feel together. Never know how you feel about an idea until you see it fleshed out!

Big Note: Another thing too, is that List tag item type error handling feels the closest to the recursive object handling for the JSON module, and the Object prototype error handling feels like it's trying to be the BigInt error, which is kind of treating Compound tag objects as primitive-ish values, which might be part of what feels weird about it's error handling. Object prototype error handling is checking the object itself, while the List tag item type error handling is checking the structure of the data, just like the recursive object handling does. It's the shape of the data, vs the thing of data itself. I think I may be on to something! :smiley:

Offroaders123 / NBTify

List Item Type Coalescing #21