feat: add build.rs compatiblity

[stringhandler]

Overview

Introduces a new user-facing smplx-build crate so that projects can generate Simplex contract artifacts automatically via Cargo's build script mechanism, without requiring the simplex CLI to be installed.

Motivation

I pulled the Simplicity lending demo but it doesn't build with a simple cargo build. This PR allows users to add to build.rs and [build-dependencies] in Cargo.toml, similar to tonic-build or prost-build.

Testing

You can test this by referencing the crate smplx-build under [build-dependencies] in Cargo.toml and adding this to your build.rs (create if doesn't exist):

fn main() {
    smplx_build::generate_artifacts!();             // reads Simplex.toml
}

Then cargo build will regenerate src/artifacts if the files have changed.

In addition, I've added some extra config builders for people who don't want to use Simplex.toml. These can be easily removed if they bug anyone, but seemed good to add for completeness.

Examples

// 1. Macro — simplest, panics on error (idiomatic for build scripts)
fn main() {
    smplx_build::generate_artifacts!();             // reads Simplex.toml
    smplx_build::generate_artifacts!("my.toml");    // explicit path
}

// 2. Free function — handle the error yourself
fn main() {
    smplx_build::generate_artifacts("Simplex.toml").unwrap();
}

// 3. Builder — configure without a Simplex.toml, or override specific fields
fn main() {
    smplx_build::Builder::new()
        .src_dir("simf")
        .out_dir("src/artifacts")
        .simf_files(["**/*.simf"])
        .generate()
        .unwrap();
}

Notes

The existing internal codegen library is renamed smplx-build-internal to make room for the new public crate, which wraps it with a proper build.rs-oriented API

[Arvolear]

Ok, that's a good idea as currently we need to run simplex build and then simplex test separately for the tests to work. However, since simplex test is basically a macro wrapper around cargo test, having this automatic building pipeline may simplify the interaction a bit. Although I'm wondering if it is possible to achieve the same result without an additional crate.

[stringhandler]

It's a common pattern to have it in its own crate so that it's only referenced at build time through [build-dependencies] and otherwise excluded from the actual compile.