Link librav1d against C dav1d and seek_stress instead of Rust versions

[thedataking]

Closes #807 and #803.

When the test_rust meson option (on by default) is set, use a custom meson command to build librav1d.a and link dav1d and seek_stress with it instead of libdav1d.

Notes:

• Using the subprojects feature of meson doesn't seem to be an option since it requires a specific directory layout.
• Cross-compiling isn't supported.
• The macOS build behaves differently than local macOS, possibly due to meson version differences. Didn't root cause.

[kkysen]

Could you clarify, does this preserve the ability to build librav1d linked against Rust dav1d and seek_stress binaries? If not, I'd like to keep that, as that's type checked, unlike linking against C. It might suffice just to compile this to get the type checking, as opposed to running tests with both the C and Rust CLI binaries.

Also, with this change, how do I build and test things and also run cargo independently so I get normal errors that aren't swallowed? Is it intended that I run cargo independently first to see errors, then run meson which runs cargo, whose compilation is cached?

Also, could we use cargo's --profile option instead of --release?

[thedataking]

Could you clarify, does this preserve the ability to build librav1d linked against Rust dav1d and seek_stress binaries?

Yes, cargo build works as usual this only affects how things are built when using meson. When you cargo build, it links against the Rust version of the dav1d CLI tools which are also fixed in this PR.

Also, could we use cargo's --profile option instead of --release?

I think that would be confusing. The idea is to match build types such that if we configure meson for a debug build, it links against libravid.a with debug symbols.

[randomPoison]

Looks good to me.

[randomPoison]

Are these CPU flag changes necessary as part of this, or was this you fixing another issue in the same PR? It's fine either way, I just don't see the obvious connection with the build system changes.

[kkysen]

I think this is to fix #803.

[thedataking]

I think this is to fix #803.

Correct.

Are these CPU flag changes necessary as part of this, or was this you fixing another issue in the same PR?

No, this could have been split into two easier-to-review PRs. Sorry for the confusion.

When building build/tools/dav1d with meson we now link against target/release/librav1d.a (if release build). That incidentally fixes #803 when using meson. To solve #803 fully, I also fixed the transpiled version so that cpumask works correctly when using cargo build.