Add architecture doc to step-runner spec

See merge request !474

Relocates the step resource implementations and their tests from
pkg/runner into pkg/runner/resource without renaming anything.
Splitting the move from the type renames keeps both diffs small
and reviewable; the renames follow in a subsequent commit per the
step-resource-package-design spec.

Now that these types live in a dedicated pkg/runner/resource subpackage,
the trailing StepResource suffix only stutters. Rename each concrete
implementation and the factory to idiomatic unsuffixed names
(FileSystemStepResource -> File, StepResourceParser -> Parser, and so
on), shorten filenames to match, and rename the unexported parser
interface inside Dynamic. The DI accessor follows suit:
Container.StepResourceParser() becomes Container.ResourceParser() and
returns *resource.Parser. No behavior change.

This is required to match
gitlab-runner!6614
and maintain compatibility with runner.

Update Go version to 1.26.1

See merge request !500

This better reflects the actual semantic now. In any case, this whole
thing will be removed when we add GracefulExitTimeout to RunRequest.

Over in !401
we concluded we need a separate Close and Cancel APIs. Close will shut
down the entire job execution, where Cancel will _signal_ to individual
steps to finish. Function types are free to do with this signal as they
choose, including initiating termination or ignoring it altogether. We
need this ability to e.g. let after_script run when the user script is
cancelled.

This will let the caller specify the grace full exit delay. Ideally this
would go in the forthcoming Cancel() API request, but the exit delay is
used when the function is constructed so we need it up front.

This will let callers signal to step-runner that a job should be
canceled. The Function implementation running the job is responsible for
implementing what happens on cancellation.

If the client does not specify a GracefulExitTimeout, we should set a
sensible default. While doing this I notices the job Timeout was missing
a default here, so I added one.

This self contained type will be the signaling mechanism for steps to
cancel execution 9and possibly other signals int eh future). It also
contains the GracefulExitTimeout value for those Function types that
implement graceful termination.

GlobalContext is the delivery mechanism to get a JobCtrl instance to a
Function implementation.

Job and GlobalContext share the same JobCtrl instance. This is necessary
for two reasons:
    1. Job.Close must wait at least JobCtrl.GracefulExitTimeout before
       returning to give the step a chance to exit naturally in response
       to a Cancel request.
    2. Job will be the one initiating the Cancel request.

Job.Cancel() just calls JobCtrl.RequestCancel() to signal to ALL the
Steps in step to cancel.

I've also refactored Close so they are isomorphic.

Do we actually want this?

To distinguish it from the Cancel method

Also sets a default value if GracefulExitTimeout was not set in the
request.

Now that the Exec Function has a JobCtrl reference, it can gracefully
shut down its subprocess.

Note that exec.Cmd.Run() can return errors other than
context.DeadlineExceeded or context.Cancelled when its context is
cancelled or expires, so we have to explicitly check if the context was
cancelled and set the error accordingly.

We'll need this to enable builtin Functions to implement cancellation.

In this case "handling cancellation" means short circuiting steps
execution when cancellation was requested.

Claude suggests this is largely a duplication of
`Test_StepRunnerClient_GracefulExitTimeout` in
`pkg/api/client/basic/client_test.go`. But it's a different level
¯\_(ツ)_/¯.

Implement Graceful Function Termination/Cancellation

See merge request !495

Extract step resource package from pkg/runner

See merge request !496