Add associated types and consts, and test whether the blocker stack bottoms out

`type Item = ..;` inside an `impl` now binds a name the same block's
signatures resolve as `Self::Item`, recorded in a pass before the signatures
are mapped so it is available when they need it. `const` in an `impl` becomes
a module-level constant named for both type and item, since Nim has no
per-type constant namespace. A `trait` declaration lowers to nothing --
trait resolution is not modelled anywhere -- but one that gives a method a
default body is rejected, because that body is code and there is no impl for
it to be emitted into.

Method arguments are now typed from the method's own signature rather than
from the receiver, which is what a method taking `usize` needs in order to
accept a bare literal.

This cleared 85 of 87 blockers across the 400-crate sample and moved the
fully-transpiling count from 2 to 3 -- the first time a feature has moved it
at all.

That prompted the question of whether the stacks bottom out: if they are
drawn from one finite pool of language features, clearing the pool clears
every stack, and the flat counts so far are just what precedes a step change.
Sampling every file rather than each crate's first blocker, 1,766
observations, says the answer is both, split by class. Distinct normalised
blocker kinds: 63 -- finite, and each one cleared is cleared for everyone.
Distinct unsupported std methods: 80, from small crates alone, against a
std surface of thousands. Distinct unknown functions: 75, which are calls
into dependencies. And 315 of the 400 crates have dependencies at all, which
is not a pool to drain but a closure to transpile recursively until it ends
at libc, proc macros or SIMD.

Among the 85 dependency-free crates, 1 of 84 transpiles in full, so features
are not the only remaining gate even there. DESIGN.md records all of it.

39 differential cases, all green.

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