explicitly specify error set of std.json.stringify

[Techatrix]

fixes #15859
This change wouldn't be necessary if #2971 was implemented, but until that happens, this will make using std.json.stringify on recursive structures easier to deal with.

[andrewrk]

#2971 is solved already, it just needs test coverage in order to be closed.

[thejoshwolfe]

This PR reverts a feature implemented explicitly by #15172 , but there was no link to a use case in that original PR, so it's hard to tell the impact of removing it. Can @mateusz834 weigh in on why custom errors from jsonStringify() were originally implemented?

[mateusz834]

I've had a custom stringifier, that required an allocator, and it was annoying that it worked fine while writing to ArrayList.Writer(), but not to other writers that didn't return the OutOfMemory.

[thejoshwolfe]

@Techatrix do you think there's a way to use some kind of generic programming to enable both use cases? It seems a little tacky to throw error.OutOfMemory into the error set unconditionally, but technically that would address the original use case.

Or @mateusz834 is this no longer a required use case? Would it break anything to drop support for the original feature?

[Techatrix]

do you think there's a way to use some kind of generic programming to enable both use cases?

Coincidentally this is exactly what I was looking into right now. The tres library uses a generic function to resolve the error set of its json parse function that could also work for stringify.

[mateusz834]

Or @mateusz834 is this no longer a required use case? Would it break anything to drop support for the original feature?

It is fine to break this.

[thejoshwolfe]

It is fine to break this.

In that case, I don't think we need to over-complicate this. 🤷 This PR seems good as-is.