Ship vendored sonic-rs in the Hex package

[lpgauth]

Summary

The published Hex package cannot be built from source. The root Cargo.toml — which is published — redirects the sonic-rs dependency to our vendored, patched copy:

[patch.crates-io]
sonic-rs = { path = "native/sonic-rs" }

but native/sonic-rs was never in the files: list, so Cargo resolves that patch to a path the package doesn't contain:

error: failed to load source for dependency `sonic-rs`
Caused by: Unable to update .../native/sonic-rs

Precompiled NIFs mask this for the eight targets the release workflow builds, so it only bites when RustlerPrecompiled falls back to compiling from source — musl/Alpine, Windows, any NIF version other than 2.15, or an explicit force_build. Those users can't install Torque at all.

This ships the crate's src, Cargo.toml, and LICENSE (the last one also being the right thing to do for vendored third-party code).

Verified by unpacking the built tarball and compiling it standalone:

$ mix hex.build --unpack -o /tmp/pkg2
$ cd /tmp/pkg2 && cargo build --release -p torque_nif
   Compiling sonic-rs v0.3.17 (/tmp/pkg2/native/sonic-rs)
   Compiling torque_nif v0.2.6 (/tmp/pkg2/native/torque_nif)
    Finished `release` profile [optimized] target(s) in 16.29s

Before this change the same command fails at cargo metadata with exit 101.

Tarball grows from ~41 KB to roughly 240 KB.

Note: this defect predates v0.2.6 — v0.2.5 and earlier have it too. v0.2.6 is tagged and on GitHub Releases but was never published to Hex, so no released package needs correcting.

[lpgauth]

@gilbertwong96 this is part of the 0.2.7 release which is now on hex.pm. Cheers!