Datamodel classes refactoring (sparse/full objects)

When implementing the fix for NAS-1823 "Activating and deactivating harvest definitions takes a long time", I wanted to factorize some code in the HarvestDefinitionDBDao, and it turned out to be complicated because HarvestDefinition and SparseXXXHarvest classes do not have a common interface, which is weird.

So full and sparse objects should define a common interface so that some DAO code can be factorized.

I would also create smaller sub-packages under dk.netarkivet.harvester.datamodel, at least to separate database code from DAO methods and model objects.