Further work on experiment of brining each DataType's specific View info into Java Classes

It is definately possible, but it ties the model and the view together to a degree that is unacceptable.
Will be factoring these clases out for now and continuing forward with all the DataType info being in each template file  & DataTypes.stg

Future Work: (Near/Immediate Term) pull these files into a seperate experimentation branch.
Future Work: (Short Term) finish the DataType info in the current lookup map to generate templateName code existing.
Future Work: (Median Term) get DRUID as a whole to generate usable code for all currently supported data types.
Future Work: (Median Term) get DRUID to implement the Generation Gap pattern effectively.
Future Work: (Median Term) get DRUID to generate a .jar library that contains the Contract Meta data (ContentDescriptor), the ORM methods
                           to be able to interact with the CP easily, and the activities and fragments to display the ContentProivider's
                           information (that which is allowed) from another application, and allow that 3rd party app to add/modify
                           (allowed) data to the Content Provider.
Future Work: (Median Term) develop documentation for DRUID (tenative document sets, some will be combined for better presentation(s))
                              a) Overall Design
                              b) Use Cases
                              c) Problems it solves
                              d) Problems it doesn't solve
                              e) Step by Step tutorial & required software ( git, maven, android SDK, String Template.jar, etc)
                                  1) for development of DRUID
                                  2) for use of DRUID to make application components
                                  3) for management/non developers, how to make contracts
                                  4) for developers, how to make new DataTypes & template files.

Future Work: (Long Term) This is all under experimental, and written down for archival purposes of current though experiment
                         on the topic, and no work on this is being currently planned:

                         Develop possible multiModel approach which allows 1 model for 'contract' and model(s) for each supported
                         DataType. This would then allow the generator/parser/etc to not have to be updated when adding support for
                         additional DataTypes (such as 'Image' or 'Video file', etc).

                         Currently the template files need updated to reflect any changes/additions to the supported DataTypes,
                         and this will work for now, but would be nice if the allowed 'DataType(s)' could be more customizable in
                         a quick manner. This would allow others to develop their own 'DataType(s)' and use them in their own
                         projects without much changes either the template files, or to the DRUID generator. This would also allow
                         the removal of types (for whatever management decision would decide this) easily from the "DataType Model"
                         (for lack of a better term currently).

                         Possible future use case: DRUID being a single 'application' and you give it your:
                             DataTypes.jar
                             Contract file
                             Template files( as a .jar?)
                             (maven pom file for overall configuration or a possible external configuration file for use w/o maven)
                         and get the desired output.
Merge branch 'master' of github.com:mawalker/druid