Usability concerns with exec module

[vkorbes]

These are some usability issues I came across when trying to set something up with the exec module type, and ideas to fix them:

1. We don't have an example of it in action. Will push one soon.

2. The working directory for any script I call is .garden/build/modulename, as opposed to simply my module's directory. From the description in our docs, "A simple module for executing commands in your shell," I would assume I could run scripts in my module's directory and that would work. But since the working directory is somewhere else, that's not the case. IMHO this should be fixed at a framework level. As is, to copy a built artifact somewhere else, I'll need a lot of extra ../s in my cp command. This would be fine if it were explicit, but...

3. Even with -l debug, there's no output of what's going on. I had to go into Garden's source code and add a bunch of console.logs to garden-service/src/plugins/exec.ts to understand what was going on. @eysi09 mentioned we could apply the same solution as the container type (feat(container): output build log while building with debug log level #1144) here.

4. execa returns a unhelpful/inaccurate error message... If the exec's module config file calls a script, and anything in this script returns a non-zero value, execa will output: Command failed with exit code 1 (EPERM): /bin/bash myscript.sh. EPERM means operation not permitted, which is not the case at all. You wouldn't expect to get EPERM when trying to copy a file that doesn't exist (this should be ENOENT), or when calling e.g. java with the wrong number of parameters, but that's what happens. No idea how to address this one.

[eysi09]

We figured out that 4 is a non-issue, right?

[eysi09]

I have a PR in progress that covers the other three.