Enhance `content` schema or add a more permissive schema

[tingerrr]

Currently, with something like z.content I would've assumed to be able to pass sym.dagger, but It turns out this is of type symbol. This makes sense of course, but a user my expect z.content to allow this too.

I think symbol should be added to z.content, as it is trivially converted to content. I wonder if there are any other types we may have missed that ought to be included here.

[jamesrswift]

I think there are two cases where z.content is useful, and that's when you want to start with content type, or end with content type. As by the sounds of it, the goal is closer to just rendering an input, then I'd suggest the content coercion

[tingerrr]

As by the sounds of it, the goal is closer to just rendering an input, then I'd suggest the content coercion

This will not work, the content coercion is too lossy, anything can be turned into content, but not anything is content from the perspective of a package API. If a user passes an array where I use a content coercion, then I expect it to fail and tell the user this is wrong. A user may just change something in a hurry, not check the output, and produce a bogus document.

[jamesrswift]

Fair, in which case we'd need a good list of things that are closer to content than not (string, number, symbol, version, etc)

[tingerrr]

For now, I've simply extended it to symbol in my code, as symbols are made up of different versions of Unicode code points, which are essentially strings from Typst's perspective.