Move DataModules to torchgeo.datamodules

[adamjstewart]

This is a pretty disruptive change to our API, and a lot of work to move everything, so I'll do my best to justify this. I'm hoping that this is the last time we have to move these.

Originally, all of our DataModules were defined in torchgeo.trainers. However, we decided to move them to torchgeo.datasets in #220 since the filenames had so much overlap with the dataset filenames (ideally there should be a one-to-one correspondence between Datasets and DataModules). This introduced a circular import issue (#276) because our samplers import GeoDataset/BoundingBox and our DataModules import our samplers. Although there are workarounds for this, circular import issues are generally a sign of a poor design. In this case, the torchgeo.* components were not standalone and distinct enough.

This PR solves the issue by moving all DataModules to their own torchgeo.datamodules namespace. Now our components have the following import dependence:

• datamodules -> datasets, samplers
• datasets
• models
• samplers -> datasets
• trainers -> datasets (removed in Remove dataset-specific trainers #286), models
• transforms

As you can see, no more circular import dependencies. Aside from avoiding circular imports, the other motivation of this PR is that it allows us to remove all imports in torchgeo/__init__.py. Some of those imports were hacks to avoid circular import issues. I'll remove these imports in a separate PR to keep this one focused.

[isaaccorley]

Should this be moved above to the C section?

[adamjstewart]

Hmm, it's sorted under "Tropical Cyclone". I think we may want to consider renaming the DataModule to be more consistent with the Dataset. But let's do that another day.