Add binary compatibility validator

[mateuszkwiecinski]

Closes #2111

Description

I wasn't sure if I should add a Changelog entry, since this does not affect consumers at all 👀

Binary compatibility validator will compare the commited public API surface with current one. Task apiCheck will run on every check invocation.
If the public API changes, the apiCheck task will fail and will require dumping a new one with ./gradlew apiDump.

I'm proposing to verify binary compatibility of every project that is published (and can be consumed by third party clients)

Checklist

Before submitting the PR, please check following (checks which are not relevant may be ignored):

• Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
• At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
• Tests are added
• KtLint format has been applied on source code itself and violations are fixed
• CHANGELOG.md is updated
• PR description added

Documentation is updated. See difference between snapshot and release documentation

• Snapshot documentation in case documentation is to be released together with a code change
• Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master
• In case of adding a new rule, it needs to be added to experimental rules documentation

[paul-dingemans]

I wasn't sure if I should add a Changelog entry, since this does not affect consumers at all 👀

I am not 100% strict in this. For example, documentation change I never add. In this case, I would like it to be added to the changelog as it informs our API consumers that we took measures against unintended API changes.

[paul-dingemans]

I'm proposing to verify binary compatibility of every project that is published (and can be consumed by third party clients)

Yes, that seems like a fine plan.

[paul-dingemans]

Tnx for implementing this!