Up to now the presence of the deployable (source) was checked late
by the NeoCommandLineHelper. The code doing this is surrounded by
the try/catch which finally also puts the log written by the neo
toolset into the job log in case an exception occured.
The check for the deployable returns with the same type of
exception like a failed neo command. Hence we cannot distiguish (ok,
would be possible to parse the exception message, but that is ugly).
When the exception is triggered by the missing deployable we try to
cat the neo log into the job log. But at this point the neo log has
not been provided - neo has not been called at all in this case.
Hence `cat logs/neo/*` in turn fails.
In order to avoid such a failure we check now for the presence of the
deployable earlier before launching the neo toolset.
Since the deployable is used in any deploy mode case no further check
for the deploy mode is required prior to the check for the deployable.
from property dockerImage we cannot conclude that we are in fact running inside a docker environment.
Step dockerExecute has some checks if we are in a docker context. If not there is a fallback to the
local environment.
The docker image property is provided from resources/default_pipeline_environment (value: 's4sdk/docker-neo-cli').
Hence a value will be present all the time (exception: someone configured null/ empty string explicitly). So we
will enter the corresponding code block anyway.
It is IMO also desirable to have the neo log in the job log when running inside a non-docker setup since this
simplifies troubleshooting anyway.
Before the test we remmber which test is currently running.
During the test we collect all the calls to steps.
Beside that we persist the names of all steps within this shared
lib itself.
After the test(s) we write a corresponding json file. In fact we
write the file after each test, which is too often. But since we
don't know which test is the last test we can't do better.
The resulting file can be used later on for resolving the plugins
contributing the particular steps.
With that we are able to create a list of required plugins for each
step.
