Reduce cyclomatic complexity of ProjectConfig.ValidateProjectScripts()

[febbraro]

Our new static analysis tooling identified ProjectConfig.ValidateProjectScripts as failing on cyclomatic complexity. That's a fancy phrase for "too much nesting of logic/too much code in one function".

HELP WANTED
This issue is a great opportunity to learn Golang, the contribution workflow of rig, and incidentally improve rig!

Notes

• You can review the code for this function here: https://github.com/phase2/rig/blob/develop/commands/project_config.go#L142
• We use a nolint directive in the function comment to disabling this linting rule, in order to pass this issue, be sure to remove that comment first.
• The simplest solution is to flatten the logic, possibly creating some helper functions. However, if you want to get fancy, you can evaluate whether adding a validation library might make sense. On a quick google exercise, there are https://github.com/go-playground/validator, https://github.com/go-ozzo/ozzo-validation, and https://github.com/asaskevich/govalidator whose relevance, quality, usage, and licensing would need to be evaluated before looking at adding them to the project and using them to facilitate outrigger.yml validation in general.

Adding a Library
docker-compose run --rm base
dep ensure --add github.com/awesome/lib

Testing

• Use docker-compose run --rm lint to apply the full suite of static analysis tools. If there is a failure, you aren't done yet!
• Use docker-compose run --rm compile to confirm your code compiles.
• You can use the binary resulting from the compilation step (located in ./build/darwin/rig) to test that validation works... navigate to a project, reference this binary instead of your global rig, and see how rig project help works.

[grayside]

Expanded the initial note into a full new contributor orientation.

[grayside]

Note that #90 points out a problem with the current error logging: namely that it can interference with the output of completely unrelated commands. That is not necessarily in scope here but refactoring should keep in mind that we'd prefer to give the caller more control over when & how this logging happens.