stackeval: ApplyChecker is now Applyable

We chose this name originally to communicate that implementations are only
responsible for checking that an apply was successful, but in future
commits this interface will also gain the additional responsibility of
helping to gather the information required to understand the dependency
relationships between components that will then drive the scheduling of
the apply actions during the apply phase.

internal/stacks/stackruntime/internal/stackeval/README.md

@@ -338,10 +338,10 @@ object in its callback:
   which can return an arbitrary number of "planned change" objects that
   should be returned to the caller to contribute to the plan, and an arbitrary
   number of diagnostics.
-- `ApplyPhase` calls the `CheckApply` method of interface `ApplyChecker`,
+- `ApplyPhase` calls the `CheckApply` method of interface `Applyable`,
   which is responsible for collecting the results of apply actions that are
   actually scheduled elsewhere, since the runtime wants a little more control
-  over the execution of the side-effect heavy apply actions. This returns am
+  over the execution of the side-effect heavy apply actions. This returns an
   arbitrary number of "applied change" objects that each represents a
   mutation of the state, and an arbitrary number of diagnostics.
 

internal/stacks/stackruntime/internal/stackeval/applying.go

@@ -27,15 +27,15 @@ type ApplyOpts struct {
 	PrevStateDescKeys collections.Set[statekeys.Key]
 }
 
-// ApplyChecker is an interface implemented by types which represent objects
+// Applyable is an interface implemented by types which represent objects
 // that can potentially produce diagnostics and object change reports during
 // the apply phase.
 //
-// Unlike [Plannable], ApplyChecker implementations do not actually apply
+// Unlike [Plannable], Applyable implementations do not actually apply
 // changes themselves. Instead, the real changes get driven separately using
 // the [ChangeExec] function (see [ApplyPlan]) and then we collect up any
 // reports to send to the caller separately using this interface.
-type ApplyChecker interface {
+type Applyable interface {
 	// CheckApply checks the receiver's apply-time result and returns zero
 	// or more applied change descriptions and zero or more diagnostics
 	// describing any problems that occured for this specific object during

internal/stacks/stackruntime/internal/stackeval/main_apply.go

@@ -236,7 +236,7 @@ type applyWalk = walkWithOutput[*ApplyOutput]
 // be scheduled separately or this function will either block forever or
 // return strange errors. (See [ApplyPlan] for more about how the apply phase
 // deals with changes.)
-func (m *Main) walkApplyCheckObjectChanges(ctx context.Context, walk *applyWalk, obj ApplyChecker) {
+func (m *Main) walkApplyCheckObjectChanges(ctx context.Context, walk *applyWalk, obj Applyable) {
 	walk.AsyncTask(ctx, func(ctx context.Context) {
 		ctx, span := tracer.Start(ctx, obj.tracingName()+" apply-time checks")
 		defer span.End()

internal/stacks/stackruntime/internal/stackeval/walk_dynamic.go

@@ -11,7 +11,7 @@ import (
 // evaluation phases, which currently includes [PlanPhase] and [ApplyPhase].
 type DynamicEvaler interface {
 	Plannable
-	ApplyChecker
+	Applyable
 }
 
 // walkDynamicObjects is a generic helper for visiting all of the "dynamic