P3. Rework execute functions step. Expose step-function to build own executor

[SerhiiRI]

Motivation

Real life shows me that the internals of status-map is very presios by the many reason. For building UI, for checking something before the execute. To avoid dancing with hooks or parametrization i decide to expose our internal steps outside. That allow to

1. Implement user own execute function safely.
2. Execute 3 first steps, hold the process of execution to check something, run the rest of steps.

Example from the tests.

(deftest execute-steps-halt-and-resume-test
  (testing "Pipeline can be halted before commands run, inspected, then resumed to completion"
    (let [instruction {"a" 1 "b" {:commando/from ["a"]}}
          steps (commando/steps-pipeline-default [cmds-builtin/command-from-spec])
          halted (commando/with-execute-context nil
                   (fn []
                     (commando/execute-steps
                       (smap/status-map-pure {:instruction instruction})
                       (take-while #(not= (:step-name %) :step-execute-commands!) steps))))
          resumed (commando/with-execute-context nil
                    (fn []
                      (commando/execute-steps halted
                        (drop-while #(not= (:step-name %) :step-execute-commands!) steps))))]
      (is (some? (:internal/cm-running-order halted)) "Running order is available before commands run")
      (is (nil? (:internal/cm-results halted)) "Commands have not run yet")
      (is (commando/ok? resumed))
      (is (= 1 (get-in resumed [:instruction "b"])) "Resumed run executes the deferred commands"))))

as You see the problem with injection additional steps almost gone, we allow advanced (controlled) usage with creating self implementation of steps-pipeline-default, where for example :step-execute-commands! may even been replaced on backend for something more parallel or even group few steps in one to speed up the execution. Status Map kept almost all needed metainformation.