Make first-time encounters easier for contributors

First time contributors of projects using `commitlint` run into our checks unprepared.

This increases friction at a point critical for every OSS project, up to the point where commit messages are lost:

* https://github.com/remy/nodemon/pull/1110#issuecomment-334178055
* https://github.com/GoogleCloudPlatform/cloud-trace-nodejs/pull/543
* https://github.com/google/ts-style/pull/8
* https://github.com/uPortal-Project/uportal-app-framework/issues/535

We should do more to make contributing as easy as possible when `commitlint` is used

1. `@commitlint/template`. Will prepend commit messages with example messages generated from our config. Idea snatched from https://github.com/remy/nodemon/pull/1110#issuecomment-334178055, example: [lennym/commit-template](https://github.com/lennym/commit-template). This introduces a second `husky` commit hook, increasing install complexity. Decide if `commitlint init` should set this when implemented: https://github.com/marionebl/commitlint/issues/48

2. `commitlint restore`: Let users restore commit messages that failed the tests for repeated edits. Theoretically we could even create a `preparecommitmsg` hook to read that from an agreed-upon place?

3. [commitlintbot](https://github.com/paulirish/commitlintbot): Support commitlintbot to become the go-to tool for projects opting for linting on PR/Squashing level only. This approach moves the burden of commit conventions to project maintainers entirely.