Simply semantic-release config and increase flexibilty

ideas.md

The current plugin system aims to make every step of semantic-release customizeable. There is a lot of overhead to this though.

Idea:

1. Remove verifyConditions.
2. Hardcode one check that implements every CI server out there. (Mappings for each service are trivial to add, much like in https://github.com/auchenberg/volkswagen)
3. Add an option to surpass this check.

With this it would "just work™" on any CI server. If there is custom behavior required this can simply be run before the semantic-release command: e.g. verify-unicorns && semantic-release pre && npm publish && semantic-release post. This custom check could also set an env var read by semantic-release, so the internal CI check is surpassed.

Offers same flexibility, less to no config.

Idea:

Remove verifyRelease.

The verification can be performed with custom scripts outside of semantic-release: semantic-release pre && verify-release && npm publish && semantic-release post

Idea:

Implement a post step that works for GitHub, GitLab and BitBucket, and automatically performs the right thing based on auth exposed, and repository URL. If this needs to be customized: semantic-release pre && npm publish && custom-release-notes If this needs to be left out: semantic-release pre && npm publish

Idea:

Implement a commit analyzer that works for all commit message styles available in conventional-changelog: https://github.com/ajoslin/conventional-changelog/tree/master/conventions Defaults to Angular, chosing another style means passing one config flag. Passing a custom parser works like it's working right now.

Metadata

If semantic-release could make extracted metadata (commits, version details, etc.) available in the environment or in a temp file, then the custom scripts could simply pick it up again without the need to extract or parse them again.

@boennemann I now have semantic-release-github-releaser and semantic-release-github-notifier ready (I believe as I haven't tried them in production.
As mentioned by stevemao in semantic-release/semantic-release#190 I think we can remove the analyzeCommits plugin end point.
Also, as noted by stevemao, we don't need a dedicated generatorNodes plugin end point either now that conventional-changelog has all the functionality we need (including presets that allow us to change the changelog output based on known formats)
That leaves verifyConditions, verifyRelease, and getLastRelease.
I don't think we need the first two. I need to look into the default verifyConditions plugin, but all that semantic-release needs is the GitHub token (which actually is only needed if you're using a GitHub release plugin), and the npm token (which is only needed if you're plublishing to the npm registry.). Requiring that semantic-release is running on a particular CI doesn't seem useful. Also, it should be up to the user to know how to check that semantic-release is only called once for their I system.
For verifyRelease I would expect that detecting breaking changes would be done in the pull request, not when you're finally ready to publish.
For example, I could setup my build to detect breaking changes for pull requests, and if a breaking change is detected, verify that the pull request commit message has the BREAKING CHANGE tag in it. If not, fail the build.
Therefore I think we can get rid of both verifyConditions and verifyRelease.
That just leaves getLastRelease, and a refactor of semantic-release to resolve many of the outstanding issues.