Correct the claim that dependencies are a different kind of problem

I had been calling the dependency closure a different problem from the
language, and that was wrong: another crate is just more Rust. rustnim
already takes many files and flattens modules, so a dependency's sources are
simply more of them. Tested directly rather than argued -- a crate with `mod
mathlib;` fails alone, succeeds when mathlib.rs is passed alongside, and the
output matches rustc's.

So the wall is two other things, and only one of them is qualitative.

Scale is quantitative: libcosmic resolves to 741 crates, every one of them
Rust, each needing its own blocker stack cleared. That is the same problem
741 times rather than a different problem.

The floor is not Rust at all, and this is the part that actually matters.
Proc macros are compile-time programs -- 37 of the 400 sampled crates are
proc-macro = true, and syn, quote and proc-macro2 have 155 dependents between
them in libcosmic's tree. They bottom out in proc_macro::TokenStream, which
the compiler provides and which exists as no crate in the registry: there is
nothing to transpile, they have to be run, and what they emit is the Rust you
would then translate. libc is 129,594 lines holding 121 function bodies, with
the rest declarations binding to the C library; wgpu, winit and the *-sys
crates have the same shape. Then SIMD and the parts of core the compiler
implements directly.

DESIGN.md now says this instead of the vaguer claim it had.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>