Agregando chekstyle alternativo

El nuevo checktyle es menos burocrático que el default de Zauber, en el sentido
de que tiene menos restricciones sintácticas, pero es más estricto en cuanto
a métricas de calidad de código.

En terminos generales, el checkstyle default tiene como filosofía preventiva:
prohibir código que, en manos inexpertas, podría ser mal usado, pero es liberal respecto de código
que es difícil de entender.

Este checkstyle, por el contrario, es correctivo: deposita mas confianza
y responsabilidad en el programador, y es liberal respecto de ciertos elementos sintácticos, en pos de lograr
código mas legible y sucinto. Pero, en compensación, es mucho más estricto respecto de métricas como longitud de archivo,
longitud de métodos y complejidad ciclomática.

Algunas restricciones, entonces, han sido relajadas, mientras que otras han sido reforzadas.

Relajadas:
 * Design for extension. Se deshabilita. En manos de desarrolladores experimientados, que entienden las implicancias de hacer super, implicia burocracia adicional, y reporta mínimos beneficios. Además, es incomptable con técnicas de mocking, y produce errores inesperados con Hibernate (a través de Javassist).
  * Javadoc Method: se relaja para que solo sean obligatorios en métodos protegidos o públicos.
  * Avoid Star Imports: deshabilitado, porque son usadas ampliante en combinación con import-static.
  * Return Count: pasa de 3 a 5. La justificación es que el código estructurado empleando una variable de retorno y asignación destructiva es menos legible, propenso a error, fuerza la definición de valores iniciales superfluos, resultando en código mas imperativo. Por el contrario, definir reglas del estilo "si X entonces Y", evita la proliferacion de if-else, tiene un estilo más funcional y declarativo, y elimina variables intermedias superfluas.
  * FinalParameters: ningun programador con un mínimo de experiencia asignaria un parámetro, y agregar final a cada uno es burocrático. El problema aun puede evitarse señalando las asignaciones de parametros como error de chectyle (regla agregada, ver abajo)

Reforzadas:
  * Method Length: Pasa a 120, antes estaba en 150
  * Unsued Imports: se habilita la validación
  * NestedTry/For/IfDepths: se habilita en 2 para try, 2 para if y 3 para for
  * MaxBooleanExpressionComplexity: se habilita en 4
  * AnnonInnerLength: se habilita en 80
  * CyclomaticComplexity: se habilita en su default de 10
  * FileLength: se pasa de 2000 a 1500
  * StrictDuplicatesCode: se habilita en su default de 12
  * ParameterAsignment: se habilita
rename checkstyle for boutique
Relajando aun mas las reglas:

* Se habilita snake_case para nombres de metodos de tests. Los buenos nombres de tests son largos, y es_mucho_mas_claro_leer_asi que tenerQueLeerEstaOtraFormaDeEscribir.
* Se permite que el nombre de un parametro oculte un atributo. El IDE ya provee feedback visual con colores para diferenciar el acceso a una variable de un atributo. Evita tener metodos que reciben parametros con el estilo smalltalk: Reporte unReporte.
* Se permite que los metodos no tengan javadoc. Es mejor tener criterio de decision sobre la documentacion a tener que escribir /** */ sobre los metodos para evitar al checkstyle. Cada programador es responsable de documentar las APIs que escribe.
Merge pull request #3 from zauberlabs/feature-simple-checkstyle

Feature simple checkstyle