fn rav1d_log: Replace with safe write! calls to a fully safe Rav1dLogger

[kkysen]

• Fixes Use log crate for debug logging #171.

The existing variadic and unsafe rav1d_log calls are replaced with write! calls to an Option<Rav1dLogger> field. enum Rav1dLogger's interface is fn write_fmt, which write! calls. These are defined as part of trait Rav1dLog, similar to trait {io,fmt}::Write. The difference is that no errors are returned (we don't really need them) and crucially, they are &self methods as opposed to &mut self methods, which keeps things much simpler for the borrow checker.

enum Rav1dLogger can be Dav1d or Std{out,err} for now. The Dav1d variant is necessary to convert to/from the Dav1dLogger, and Stderr is the default logger used (and Stdout is trivially similar). There will presumably be other loggers desired, but it's easier to leave those for later once we know their desired behaviors better.

The Dav1d variant is called by implementing fmt::Write, which lets us just implement fn write_str and have fn write_fmt auto-implemented. fn write_str is implemented correctly but with poor performance by printing byte by byte. This is to avoid dealing with intermediary null characters and having to allocate a new null-terminated CString. This is for logging so perf isn't important, and if better perf is desired, users can switch to the Rust API, which has no such limitation.

Then we construct a bijection between {D,R}av1dLogger to allow the bidirectional conversions needed in the DAV1D_APIs. This is done by storing the Std{out,err} variants as special Dav1dLogger::callback fns. During the conversion back, if the callback is one of those special fns, we can decode it back into the same Rav1dLogger it originally was. With use of the Dav1dLogger::cookie field, this can be extended to other Rav1dLogger variants in the future as well.

This also makes it fairly easy to eliminate #![feature(c_variadics)] (it's only used for the special marker fns now, but those can be implemented a bit differently).

[CrazyboyQCD]

Since rust-lang/rust#117472 has been merged, I think cstr crate could be removed sometime.

[kkysen]

Since rust-lang/rust#117472 has been merged, I think cstr crate could be removed sometime.

Oh, that's awesome! Thanks for letting me know! I saw the RFC got accepted earlier but I didn't realize it would be stabilized so soon. We'll remove cstr once 1.76 is released.