Implement dav1d-rs's Rust API

[leo030303]

I've copy pasted the PR from #1362 and updated it with some of the suggestions made on that pull request. The main changes are:

• Have all the public-facing Rust API code in its own file.
• Used some enums from rav1d instead of redefining new ones, and added in doc comments from the original dav1d-rs library to a few items.
• Removed as much unsafe code as I could and replaced it with the Rust methods from rav1d as much as possible.

It currently works as a drop-in replacement for dav1d-rs; adding in use rav1d as dav1d; to my fork of image makes everything work fine.

The only functional changes I made are I removed the unsafe impls of Send and Sync for InnerPicture so Picture is no longer Sync or Send. I looked through the code and I don't believe DisjointMut<Rav1dPictureDataComponentInner>, which is a field of one of its children, is thread safe, though I'm open to correction there; I'm pretty unfamiliar with unsafe Rust.

I also don't have safety comments on the two unsafe blocks in rust_api.rs; I'm unsure what these would look like, so open to suggestions there. These are mostly taken verbatim from the old pull request.

• Closes Provide Rust API #1252.

[kkysen]

Thanks for the much safer implementation! I'm still taking a closer look at the unsafes, as the few remaining are still quite critical, but I wanted to give some initial feedback in general first.

[kkysen]

@leo030303, could you rebase this on main? There are a lot of other commits in here now, so it's harder to review.

[kkysen]

So the self.pending_data.take() here replaces self.pending_data = None and then moves the Rav1dData to the local variable pending_data. That local variable is dropped no matter what, so the mem::take(&mut pending_data) should be redundant.

[kkysen]

I think this needs its own SAFETY comment. There's none in rust-av/dav1d-rs#121.

[leo030303]

To be honest I don't know what a valid SAFETY comment looks like, I've never really used languages like C or unsafe rust so I'm unsure how you'd guarantee there's no undefined behaviour when you're using raw pointers, if yourself or anyone else has any suggestions here I'd be happy to help review

[kkysen]

Sorry again for such a long wait. I left some comments, and could you also rebase to remove the merge commits? It's also important that we keep each commit buildable/testable so that we can do benchmarking on each commit, so if any commits aren't, could you rebase them such that they are? Thanks!!

[Shnatsel]

This PR has a rather long commit history. Rewriting the history with such granularity at this point is completely impractical. It's probably best to squash it down to one commit before merging if every commit on main being testable is a requirement. Github has this as an option in the merge button dropdown.

[tats-u]

@Shnatsel How about "Squash and merge" instead of "Create a merge commit" or "Rebase and merge"? It will automatically do it.

[kkysen]

This PR has a rather long commit history. Rewriting the history with such granularity at this point is completely impractical. It's probably best to squash it down to one commit before merging if every commit on main being testable is a requirement. Github has this as an option in the merge button dropdown.

Yup, this is fine, too. I pulled out the two small changes that seem more separate (#1468, #1469). The rest seems fine to be squashed into one commit.

[leo030303]

@kkysen Thanks for the review, resolved most of the comments, and happy to see all the outside interest in the PR!