Initial prototype for generating pojo classes on the fly to aid testing
multiple combinations
starting to work on creating a test that covers as many possible
interactions of features as possible
Experiment with a few different approaches to data-driven testing 
(using TestNG).
ignore detrius
While it makes sense to provide the type via a data provider, providing
individual values feels like overkill - we end up with too many small
tests. This would only get worse as we add more axes to our test cases.
Better to have this test pass than fail...
Run both TestNG and Junit tests
Rather than having separate tests for arrays and non-arrays, let arrays
be another type.
Test arrays stored in Object fields, both with and without
@CanBeArray
import cleaning
Just as with doEquals and doHashCode, doToString should only dive into
Object fields that contain arrays if @CanBeArray is present.
The benefit of initiallize is now becoming clearer. Additionally, the
presence of a few additional formatter instances should not be too
significant, especially considering that these are tied to classes.
Rename PrimitiveType to BaseType, since String is not primitive
* Unprintable chars are now formatted as \u00?? instead of 0x??
* Type instances now can do formats and hashCodes on their values
Better support for formatting arrays:
* Formatters now have separate method for formatting objects which might
  be arrays and those that should not be considered as arrays.
* We no longer rely on the formatting methods in Arrays, since those
  create their own StringBuilders. Additionally, this allows us to
  handle char arrays nested inside other arrays in the same way we
  handle simple char arrays.
Fix cast
Guavafy our providers
Type learns about array depth
DeepArray implies CanBeArray
* Test DeepArray use cases.
* Move providers to TypeProviders