CI Steps Phase: Users can run steps in their own execution environment
## Problem
The initial version of the step runner is deployed as a Docker image. This requires customers to use a GitLab runner executor that supports Docker containers, and it requires them to run the CI/CD job inside the step runner Docker container instead of their own Docker container, VM or other execution environment.
## Success criteria
- Customers can supply the `image` on a CI/CD job that uses steps.
## Out of scope
- Running steps in various Runner executors will be handled in a subsequent epic, https://gitlab.com/groups/gitlab-org/-/epics/16962+
- Running steps on different operating systems will be handled in a subsequent epic, https://gitlab.com/groups/gitlab-org/-/epics/15074+.
## Example
```yaml
my-job:
image: alpine:3.18
run:
- name: blue-green-deploy
step: gitlab.com/my-steps/deploy
inputs:
target: blue
artifact: bundle.zip
```
## Proposal
The step runner should be installed into the runner execution environment. Step runner should start as a service on a known port. GitLab runner will connect to the Step runner using gRPC to start jobs, follow logs, check status of jobs, and receive results of completed jobs.
## Reference
This phase relates to `Phase 3: steps, steps everywhere!` in https://gitlab.com/gitlab-org/step-runner/-/issues/112#note_2044603629.
epic