SimplicityHL versioning

[Sdoba16]

---

• This PR suggests a bug fix and I've added the necessary tests.
• This PR introduces a new feature and I've discussed the update in an Issue or with the team.
• This PR is just a minor change like a typo fix.

---

Motivation

A contract's compiled Simplicity — and therefore its CMR, address, and spend — depends on the exact
SimplicityHL compiler version. Until now that version was whatever simplicityhl crate happened to be
linked into the SDK, so upgrading Simplex could silently change every contract's address.

What this does

• .simf files can declare the compiler range they are written for: simc ">=0.7.0";
• simplex build resolves the newest release satisfying every declared range and pins it in simplex.lock (with per-platform binary hashes). A satisfying lock keeps builds off the network.
• New simplex toolchain command manages the compiler store (~/.simplex/compilers): resolve/pin by default, plus list, install, remove, dir.
• Programs compile at runtime with the pinned out-of-process simc, so addresses stay stable across compiler upgrades. The linked frontend does only version-stable work (flattening, ABI typing).
• Contract ABIs are extracted once at build time into .abi.json sidecars; the macro and runtime read those instead of re-invoking a compiler.
• Dependencies resolve through the pinned compiler via --dep remappings, identically at build time and runtime.
• -v/-vv compiles with --debug and traces via the artifact's debug symbols.

Compiler releases are currently published at Sdoba16/SimplicityHL for the testing