Let `read` always return `bytes`

I propose to remove the encoding argument from the read function and let it always return bytes. Thus, call sites would change like this:

• read(path) becomes str(read(path))
• read(path, encoding: none) becomes read(path)

The read function predates the bytes type and thus had no choice but to return a string originally. The encoding argument was introduced in https://github.com/typst/typst/commit/b8b0137504d388efbe2d1ba5082c0dcabcd8bc8a alongside the bytes type, to add raw byte reading functionality in a non-breaking way.

However, I think the API design is not great. Switching out return types based on argument generally isn't that common and bytes are simply the natural return type for a read function. There is no need to couple file loading and encodings. The read(path, encoding: none) call always feels strange to me.

The downside is that reading strings is possibly a bit more common and becomes a tad longer, but honestly I think it improves readability since with str(read(..)) you immediately know which you are operating on.

Migration path

We can do this change without immediately breaking packages like this:

• First release cycle: Warn for stringy read(path) calls that are not str(read(path)) and tell them to wrap the read call in str(..). Since str(string) is idempotent, this works today. read(path, encoding: none) calls stay the same in this cycle and don't warn.
• Second release cycle: Switch read to always return bytes and warn that encoding: none is deprecated and unnecessary.
• Third release cycle: Remove the encoding argument.

I'm interested to hear your thoughts!

Review the read function API and its call sites, then assess the proposed three-release migration: warnings for stringy calls, a bytes return type, and eventual removal of encoding. Done means the staged behavior and compatibility warnings are agreed and implemented across the migration plan.