Split c2rust-transpile (and deps) and c2rust-analyze (and deps) into two separate workspaces

[kkysen]

Right now, c2rust-transpile and its dependencies can all build on stable, while c2rust-analyze and its dependencies all require a pinned nightly-2022-08-08. However, only one rust-toolchain.toml is allowed per directory (and thus workspace), so even the stable crates like c2rust-transpile are forced to be compiled with the old nightly. This presents numerous problems that interfere with development and maintenance.

The majority of external contributions we get are for the transpiler, and they often get mired in this issue. This includes both PRs we've received, as well as others I've discussed c2rust with in-person who wanted to use c2rust transpile and contribute, but the old nightly and the issues caused by it dissuaded them.

The same goes for ongoing maintenance. We only release c2rust-transpile and its dependencies (and the simple c2rust binary), and the old nightly significantly interferes with releasing new c2rust versions and maintaining things as is. For example, we can no longer cargo publish, as the pinned nightly's cargo has a bug (rust-lang/cargo#11148), which has been fixed (rust-lang/cargo#11477), but in 1.68.0, so we can't use it. Thus, we have to cargo +stable publish -p ${stable-c2rust-crate} (#1116 (comment)). We also can't cargo update (#1116), as that updates to newer versions that don't support our old nightly (which also presents frustrating problems in incrementally updating our nightly). Newer cargo versions can use MSRV-aware resolution, but we're stuck on an old cargo. Thus, cargo install c2rust is more fragile and needs --locked. We also need to pin certain dependencies like once_cell (#1219) due to their interaction with the rustc version and std.

Upgrading from our increasingly ancient nightly also grows harder every day. Keeping up with the latest nightly is difficult enough on its own when we are close behind, as each nightly can break internal APIs we use, but the farther we get behind, we also face issues in dependencies (once_cell, syn, and Rust tooling like cargo publish). #811 is old work trying to update to a newer nightly, but it was never merged, and now there are more issues with it (merge conflicts, but also issues with dependencies not allowing incremental updates to the nightly version, and forcing larger all-at-once updates to the next Rust version).

Thus, it seems like the simplest and most permanent solution is to split the current single workspace into two: one for stable crates like c2rust-transpile and one for unstable crates like c2rust-analyze. Then c2rust-transpile can evolve on its own unencumbered.

Splitting the workspaces shouldn't be too complex I don't think. c2rust-transpile and c2rust-analyze have different dependency trees, and only c2rust-build-paths is shared between them, but actually not all of that is even needed anymore if c2rust-transpile uses stable, as rust-lang/rust#103660 means we don't have to manually set the --sysroot anymore (#1205). The c2rust binary is slightly trickier, as it's meant to also invoke tools like c2rust-analyze, but we removed the direct dependencies on the tools already, besides the stable c2rust-transpile.

[kkysen]

@folkertdev, @chrysn, @nyurik, @Lysarina, @bungcip, @GPHemsley, @domenukk, @langston-barrett, if we do this, this should hopefully reduce some of the issues you've had using and contributing to c2rust transpile.

@bungcip, could your fork bungcip/rustification@df0cdaf be upstreamed if we did this? Upgrading to syn 2.0 (#977) would be nice.

[bungcip]

hi @kkysen, happy to upstreamed my changes if we can use stable compiler version