fix(semantic-commit-linting): add semantic commit linting

[jaebradley]

The commitmsg hook fails when you try and add a commit message via git commit that does not follow conventional commit convention

[arizzitano]

This is a valuable bit of automation, but IMO too heavyweight to run for every commit. Some developers (myself included) push up a lot of WIP stuff as they're working on it, just so others can see it or CI can run against it, and those commit messages are generally meaningless. Besides, people tend to get antsy when you prevent them from committing -- even the pre-commit linter annoys some folks. Why enforce conventional commit syntax when it doesn't have any deeper implications?

The only commit message that really matters is the squash commit, right? What do you think about using the prepare-commit-msg hook instead, and only running it if the hook receives the squash param?

[jaebradley]

@arizzitano that all makes sense - I guess you could still commit using the --no-verify option? Either way, I don't really have a preference!

[coveralls]

Coverage remained the same at 99.505% when pulling 5c6b3a4 on valid-commit-message-hook into 25fe397 on master.

[coveralls]

Coverage remained the same at 99.501% when pulling 720a82d on valid-commit-message-hook into 9690fda on master.

[arizzitano]

Let's give this a try. If people find it too heavyweight we can always revert.