Remove pylint disabled exceptions

[mastersplinter]

pylint currently has disabled warnings, implemented after upgrading to pylint but that required more work than desirable in the single PR #127.

The full list of disabled checks to remove are:

• C0103 Invalid Name %s name "%s" doesn't conform to %s Used when the name doesn't conform to naming rules associated to its type (constant, variable, class...).
• C0114 missing-module-docstring Missing module docstring Used when a module has no docstring.Empty modules do not require a docstring.
• C0115 missing-class-docstring Missing class docstring Used when a class has no docstring.Even an empty class must have a docstring.
• C0116 missing-function-docstring Missing function or method docstring Used when a function or method has no docstring.Some special methods like init do not require a docstring.
• W0122 exec-used Use of exec Used when you use the "exec" statement (function for Python 3), to discourage its usage. That doesn't mean you cannot use it!
• W0212 protected-access Access to a protected member %s of a client class Used when a protected member (i.e. class member with a name beginning with an underscore) is access outside the class or a descendant of the class where it's defined.
• R1705 no-else-return Unnecessary "%s" after "return" Used in order to highlight an unnecessary block of code following an if containing a return statement. As such, it will warn when it encounters an else following a chain of ifs, all of them containing a return statement.
• R1720 no-else-raise Unnecessary "%s" after "raise" Used in order to highlight an unnecessary block of code following an if containing a raise statement. As such, it will warn when it encounters an else following a chain of ifs, all of them containing a raise statement.
• R1721 unnecessary-comprehension Unnecessary use of a comprehension Instead of using an identitiy comprehension, consider using the list, dict or set constructor. It is faster and simpler.
• W0613 unused-argument Unused argument %r Used when a function or method argument is not used.
• R0201 no-self-use Method could be a function Used when a method doesn't use its bound instance, and so could be written as a function.
• R0205 useless-object-inheritance Class %r inherits from object, can be safely removed from bases in python3 Used when a class inherit from object, which under python3 is implicit, hence can be safely removed from bases.
• R0801 duplicate-code Similar lines in %s files Indicates that a set of similar lines has been detected among multiple file. This usually means that the code should be refactored to avoid this duplication.
• Won't Fix: R0913 Too many arguments (%s/%s) Used when a function or method takes too many arguments.
• Tracked in Make schema and schema component method signatures consistent #139 W0222 signature-differs Signature differs from %s %r method Used when a method signature is different than in the implemented interface or in an overridden method.

[mastersplinter]

Per @cosmicBboy in #138

excellent!

Fixing R0913 too-many-arguments:
Option 1: Leave it as is; disabled in messages control of .pylintrc may cause problems in future
Option 2: Selectively disable the errors on existing public functions, remove it from messages control avoids problems in future, leaves the API non pylint compliant which seems messy
Option 3: Change the public API of pandera; limiting public functions to only 5 inputs
would incur breaking changes, but not necessarily a bad thing if the removed arguments were minor

I think 5 inputs for functions/methods are quite restrictive and we should stay with option 1, at least for the foreseeable future.

Fixing W0222 signature-differs:
Option 1: Leave it as is; disabled in messages control of .pylintrc may cause problems in future
Option 2: Selectively disable the errors avoids problems in future, leaves the API non pylint compliant which seems messy
Option 3: Change the way inheritance works from SeriesSchemaBase the inconsistent inheritance is challenging for new developers - I found it confusing when originally looking at pandera, so changing the inheritance approach could make sense.

I created a separate task to tackle this issue 139... I do think the __call__ method for schema and schema_component classes can be cleaned up and made more consistent, I think this can probably be resolved without making breaking changes to the public API.

R0913, will remain unfixed and W0222 is covered in #139