Add support for keras and Pytorch Lighning

[mirkobronzi]

Add support for pytorch lightning and keras. (so, in short, replacing the train loop with these more high-level API)

Also, it switched from travis to github actions.

[mirkobronzi]

Still to do:

• [x] find a way to print train and also val loss during pytorch.
• [x] w.r.t. pytorch lightning saving models, avoid that, when training resumes (so, that menas there is a last_model_v10ckpt in the output folder), the last model for the new run becomes last_model_v1.ckpt. It should stay v0.
• [x] check resuming is working with both pytorch lightning and keras.
• [x] when resuming an experiment, make sure MLFlow continues to plot on the same experiment, not on a new one.

[plstcharles]

Mirko and I discussed the PR and the remaining changes earlier today, and came up with a list of TODOs for PyTorch-Lightning:

• [ ] Add support for DataModules in parallel or in favor of the separate DataLoaders that are currently passed to the Trainer object. DataModules seem to solve a lot of potential issues of data pipelines without hurting their readability or maintainability (see the ptlightning page for info). It's not 100% clear how compatible the concept is with Keras.
• [ ] Add missing call inside LightningModule (model) implementation to self.save_hyperparameters(...); this might log stuff for MLFlow or other outputs that could be missing otherwise.
• [x] Fix the GPU assignment in the constructor of the pytorch_lightning.Trainer object (the default behavior of uploading on whatever available device seems to have changed, and CPU is used now).
• [ ] Determine whether the "TraineeWrapper" class is still needed, or if it can be entirely replaced by the "LightningModule" class that the user needs to implement. In short, the "LightningModule" should handle the loss function/optimizer on its own, so there might not actually be a need to instantiate objects elsewhere (using "load_optimizer" and "load_loss") and then pass them in via the wrapper.
• [x] Add extra kwargs/hyperparameter forwarding to the pytorch_lightning.Trainer object inside the train.py module; the Trainer object constructor can receive a ton of flags that can change the training behavior of the model, but that should probably not be hard-coded once the cookiecutter project is generated. Reading and forwarding relevant arguments from a subsection of the hyperparameter config file would be ideal.

I've got a side-project in the works that might go through some of these issues in the future, so we'll update the branch if possible!

[mirkobronzi]

Hi @plstcharles - I fixed most of the issues above and opened the PR for review. Let me know what you think..

[plstcharles]

I recently opened a PR for this branch (#22) that should fix the remaining issues and make this a gogogo-green!