refactor[next]: rename Backend to Toolchain and restructure artifact loading

[egparedes]

Adopt the vocabulary ADR 0017 already defines: the root object that carries a
program from DSL source to a runnable callable is the toolchain, not the
backend (which is one of its two halves). Renamed:

• next.backend.Backend -> next.backend.Toolchain
• Toolchain.transforms -> Toolchain.frontend
• Toolchain.executor -> Toolchain.backend
• otf.workflow.ConcreteArtifact -> otf.workflow.ProgramWithArgs
• ProgramWithArgs.data -> ProgramWithArgs.definition
• otf.stages.CompilableProgramDef -> otf.stages.CompilableProgram
• gtx.typing.Backend -> gtx.typing.Toolchain
• ffront.foast_to_past.ItirShim.definition -> ItirShim.operator_def,
  freeing the name for the renamed ProgramWithArgs field it now wraps

Beyond the renames, this restructures how artifacts are loaded.
Backend.load_artifact() was an overridable method, so a toolchain needing
backend-specific runtime data in the loaded program subclassed the root object
(ADR 0027's dace external-workspace path did exactly that). It becomes
Toolchain.loading, a plain step field defaulting to artifacts.load_artifact,
so customization is composition-time like the other three fields. The
DaCeBackend subclass is therefore deleted and run_dace_* are plain
Toolchain instances carrying a DaCeLoadingStep; the public path to the
workspace moves from backend.external_workspace to
backend.loading.external_workspace. This also keeps subclassing off the load
path, which matters because per ADR 0024 a toolchain that customizes compile
is opaque to the process-pool runner.

These are hard renames: no deprecation aliases are kept, so downstream has to
move in this release rather than drift on a compatibility layer. An alias would
have been partial anyway -- constructing with the old keyword names cannot be
aliased on a dataclass without hand-writing __init__ -- and a half-working
compatibility layer is harder to act on than one loud break.

Also resolves the TODO(tehrengruber) in backend.py asking for exactly this
rename, and records the decision in a new ADR 0029, which partially supersedes
ADR 0011 and refines ADR 0017.

Programs compile and run exactly as before. Fingerprints embed qualified class
and field names, so the ProgramWithArgs rename rotates the two persistent
translation-cache keys (gtfn, dace); this is the second such rotation in the
stack, after the module move that created otf.workflow.ConcreteArtifact.
Each is a cold rebuild rather than a stale hit because the key itself changes
-- entries written under the old name are simply never looked up. On top of
that, BUILD_CACHE_VERSION_ID (the gt4py version) already rotates these keys
at every release, so the cost is nothing extra for anyone crossing a release
boundary. The two rotations collapse into one if the stack lands in a single
release.