Modularization refactor

[tcmetzger]

To future-proof this package and make it easier to add additional functionalities, we need to modularize the code.

We propose three functional areas:

• The core functionality of processing the data into a cloud warehouse-compatible format happens in a core module (io.py). This core module always takes a NumPy array as input and only has minimal dependencies.
• All handling of concrete input and output data happens in handler modules. For version 0.1, we will have a handler module for local TIF file input and a handler module to write data to BigQuery. In future version, we could add handler modules to use data from an S3 bucket as input, store data in Redshift, etc. These handler modules have their own dependencies (such as rasterio for TIF reading, or google.cloud.bigquery for writing to BigQuery). Those dependencies only get installed when the handler module is actually used.
• Interaction with end users happens through the CLI module which wraps all functionalities of the handler modules and the core module. The CLI will also handle installation of additional dependencies (e.g. when the TIF reading handler module is used for the first time), and set up of credentials where necessary (e.g. ask for the location of the credentials file for BigQuery)

[brendancol]

@giancastro @tcmetzger Hey I have a PR up here: https://github.com/CartoDB/raster-loader/pull/23/files

[tcmetzger]

@brendancol Chunking needs to remain a user decision, because there is an upload limit in BigQuery that needs to be respected.

[tcmetzger]

@brendancol the BigQuery module should include a simple integration test (without the complex BigQuery SQL), i.e. a bytestring comparison as non regression test. (Integration test is its own task, see Issue #18)

[tcmetzger]

When generating the bytestring record (currently in .tobytes()), we need to use endian-independent code. See https://github.com/CartoDB/raster-loader/issues/29 for details!