Migration awareness

This PR makes CleanerVersion aware of migrations. A Django application including CleanerVersion-Versionables in its models can now be migrated. 
It also resolves issue #22, which comes down to wrongly generated SQL-statements due to incorrectly guessed relationship table fields (by Django).
No, not directly. Django looks up the models it has to create tables for, using the INSTALLED_APPS constant (defined in the settings-file). 

Now, we have all the models that are being used for testing CleanerVersion in versions_tests/models.py file. So, 'versions_tests' is a clean Django application making use of CleanerVersion as an additional module - just as CleanerVersion is intended to be used.
CleanerVersion itself does not specify any concrete model that has to be represented by a table on the DB. It rather defines only abstract classes that are being inherited from by concrete models specified by applications making use of CleanerVersion.

Previously, our models were embedded in the versions/tests.py file in between the test classes. Since 'versions' was specified in INSTALLED_APPS and Django is not so restrictive on where model-classes are defined within the application, everything worked out nicely. However, migrations are less tolerant, in that matter. They insist on model classes being defined in the models.py file - which motivated me to move the models.

Users using CleanerVersion DO NOT have to specify 'versions_tests' in their INSTALLED_APPS setting, unless they want to run CleanerVersion tests in order to check for compatibility issues or other problems.