Add checks for code quality: usage of tf.compat.v1 and experimental APIs

[gabrieldemarmiesse]

This should save us some work during code reviews.

We might want to discuss for this policy about experimental APIs though. See tensorflow/community#218
Should we be more permissive? Less permissive?

Closes #1279

[AakashKumarNain]

IMO we should definitely block anything that uses tf.compat.v1. If we allow this, we would be in somewhat similar scenario as py2 -> py3.

Regarding experiemtal, although most of the time things remain the same when they come out of experimental policy, IMO we should still defer its usage.

[gabrieldemarmiesse]

The reason behing disallowing experimental in user-facing code is to be forward compatible. In a perfect world, since the public API of TF is backward compatible (with the exception of experimental APIs) if we use only the public API, the users should be able to use any version of TF above the recommended one and it will work.

Experimental API are doomed to have their name changed as some points, which means that when they do and we use those APIs, it forces users to update their TF addons version. Users should have to think as little as possible about compatibility between packages.

[AakashKumarNain]

I am fine with the changes. @seanpmorgan thoughts?

[seanpmorgan]

Yeah I agree with this goal. It may be possible we're forced to use an experimental API, but this PR still enables a workaround with the blacklist if there are no other options.