crabslab v0.7.1

What's new

• #[derive(SlabItem)] is rename-aware. Generated code now targets the
  crabslab runtime the consuming crate actually sees, resolved in this order:
  1. #[slab(crate = "...")] override (serde's #[serde(crate = "...")] precedent)
  2. the dependency rename, discovered automatically via proc-macro-crate
  3. the name crabslab, as before
• crabslab-derive jumped 0.4.7 -> 0.7.0, in lockstep with crabslab 0.7.1.
  The semver break is deliberate: Cargo unifies compatible derive versions
  into a single macro node, and the split is what lets old (0.6.x + derive
  0.4.x) and new (0.7.x + derive 0.7.0) runtimes each carry their own macro
  in one dependency graph.
• New test fixtures prove it end to end: crabslab-test-two-versions (both
  runtimes renamed in one graph, one derive per runtime) and
  crabslab-test-renamed (automatic resolution, no override).
• README: new "Two crabslab versions in one dependency graph" recipe.

Who needs to act

• Single-version users: nothing. Un-renamed usage is unchanged; the new
  derive arrives through the normal re-export.
• Graphs mixing 0.6.x and 0.7.x: follow the README recipe. It covers the
  rename setup, the #[slab(crate = "...")] override, the
  use crabslab_old as crabslab; alias for old-path types, and one required
  pin: crabslab-derive = "=0.4.6". The pin matters: 0.4.7 removed
  impl_slabitem_tuples!, which 0.6.6 still calls, so fresh resolves of
  0.6.6 do not compile without it.

Also

• crabslab-derive's crates.io metadata now points at this repository (it
  previously pointed at renderling) and carries an up-to-date description.
• Nothing was yanked. Published 0.6.x and 0.4.x are untouched.