Refactor overlay around versioned MoonBit SDKs

[DzmingLi]

This is a breaking refactor.

Change the Public Pakcage Interface

In fact, the current model is inspired from rust-overlay, but rust-overlay mirrors a real upstream rustup distribution model. A Rust toolchain is first fixed to a channel or version and a host platform. Within that release's manifest, rustup can then install a named profile, optional components such as rust-src or clippy, and standard libraries for additional compilation targets. This is constrained composition within one published toolchain, not arbitrary mixing of component versions. Interfaces such as rust-bin.stable.latest.default.override { extensions = ...; targets = ...; } expose choices that rustup itself supports.

However, MoonBit has no equivalent profile, component, or target-installation contract. Each published MoonBit version is a coherent SDK: its compiler, build tools, editor helpers, runtime files, and core library are expected to be used together. The platform and core archives used to assemble it are packaging inputs with matching versions, rather than independently supported toolchain components.

The old overlay copied rust-overlay's shape without inheriting those semantics. The extra moonbit-bin.moonbit.* namespace did not identify a meaningful channel or component class; separately exposing toolchains, core, and patched moon allowed unsupported combinations; and duplicating the same versions under packages and legacyPackages made implementation details part of the compatibility surface. It also forced every internal packaging change to look like a user-facing API change.

Dropping legacy interfaces and unsupported SDKs

Dropping pre-0.10 SDKs

Version 0.10.0 is the first MoonBit SDK generation with the native helper layout assumed by the redesigned package, including the current moon-lsp entry point. The public package now promises one coherent SDK with consistent executable names, helper discovery, environment wrapping, and editor integration. Earlier SDKs use different layouts and cannot satisfy that contract through the same bundling code.

Supporting those releases would therefore require version-specific packaging branches and a separate compatibility test matrix. Considering MoonBit itself is still in beta stage, so just dropping the pre-0.10 would be a simple and clean solution.

Removing legacy interfaces

Breaking removals include legacyPackages, separately exposed toolchain components, escaped version aliases, the patched Moon implementation. The README includes a migration table for the former names.

Previously, legacyPackages existed to retain the nested moonbit, toolchains, and core sets while packages flattened them into names such as moonbit_latest. Once those internal component sets are removed, keeping legacyPackages has only two possible meanings: preserve the obsolete component-oriented interface, which defeats this redesign, or duplicate every complete SDK under a second flake path, which adds no capability.

Some other changes

Nightly is now reproducible rather than a hash pinned to an upstream rolling URL. When its contents change, the sync workflow records nightly-YYYY-MM-DD, uploads the Linux, Apple Silicon macOS, and core archives to an immutable GitHub prerelease, and advances the nightly alias.

Dropping the x86-64-darwin supports, because MoonBit officially no longer support it, so I find it no reason keep the support towards it and the old archives