Gracefully handle cli and adapter incompatibilities

[jimthedev]

Brainstorming:

As commitizen iterates, as a user I want to be notified when there is an adapter/cli incompatibility.

• Decide how adapters can communicate their cli version requirements. (semver in package.json)
• How best do we communicate an incompatibility? prompt to update, notify only?
• What if an adapter wants users to be able to specify parameters in their package's config.commitizen per Bring in categories from using repo mapbox/cz-mapbox-changelog#2
• Create and document a more robust programmatic spec for adapters

[mcwhittemore]

1. It would be nice if adapter exported the version of the cli it was made for and the cli reported back on if it was able to support the adapter.
2. If the adapter and the cli are not compatible, I think it should process.exit(1) with a clear error message. If something less than this is needed, it's most likely not valuable to the end user.
3. it would be great if prompter just got the package.json file of the working app. This is the least limiting and would let adapter developers do as they pleased. I'm sure a convention will arise in time.
4. +1 to new well documented things :)

[jimthedev]

@mcwhittemore

Per number 1 we are very strict to use semver for the prompter api so if there are ever changes to that function's api, we'll release a major version of the cli. Starting in version 3 we're going to pass more info to the adapters so that they can make more informed decisions. One of the things we'll be passing is the version number of commitizen that is running the adapter. From there, adapters can (and should) manage if they want to trigger a rejection of the commit. For example, let's say that your adapter is compatible for versions 2 and 3 of commitizen, then you can throw an warning for anything else.

Per number 2. Compatibility has become a bit tricky to determine. We're mainly defining this as the prompter interface for now. In the future if we add other interfaces for the adapters and cli to communicate then those would also be covered under that strict semver convention.

Per number 3. What if we give you the path to the directory containing the package.json. Some may want the package.json, some may want other files in that path. Would that work? An adapter would just need to fs.readFile the files they want. Is there other info you'd want passed through?