feat: implement multi-module API

[deepjoy]

Summary

Implements the full module-based API for taskmill (#37), replacing the
flat single-executor scheduler with a structured multi-module model.
Tasks are now registered and submitted through named Module instances,
each with scoped defaults, concurrency caps, state, and event streams.

Steps shipped

• Step 1 — Module struct: groups executors under a named prefix
• Step 2 — SubmitBuilder with IntoFuture for fluent, module-scoped
  submission with per-call overrides
• Step 3 — SchedulerBuilder rebuilt around modules; validates no
  duplicate names or executor collisions at build time
• Step 4 — ModuleHandle with scoped submit, cancel, pause,
  resume, active_tasks, and subscribe
• Step 5 — 5-layer default precedence chain: builder override >
  explicit field > module defaults > TypedTask defaults > scheduler
  global defaults
• Step 6 — Per-module concurrency gate; module cap and global cap
  enforced independently, with set_max_concurrency for runtime changes
• Step 7 — Namespaced StateMap: module-scoped app state shadows
  global state of the same type; executors see only their module's scope
• Step 8 — TaskContext module access (ctx.module(),
  ctx.current_module(), ctx.try_module())
• Step 9 — Cross-module child spawning via SubmitBuilder::parent()
  with TTL and tag inheritance
• Step 10 — Scheduler::modules() iterator and
  Scheduler::active_tasks() across all modules
• Step 11 — Event header.module field populated from task type
  prefix; ModuleHandle::subscribe() filters by module

Other changes

• perf: pre-snapshot module state at build time to eliminate a
  per-dispatch async lock on the hot path
• docs: rewrote quick-start, configuration, and all guides for the
  0.4 module API; expanded migration guide
• refactor(tests): split the 4050-line integration.rs into seven
  submodules by feature area