[Breaking] Pytorch 0.4 release compatibility fixes

[mttk]

#295

• Fixes volatile for pytorch 0.4 / 0.3 (with a version check)

[ssnl]

Please fix the docstrings too.

[ssnl]

It would be better if we can also raise an error/warning when the flag is set, so users can know that they need to update this.

[mttk]

I agree with the warning, but the flag isn't used only for volatile (it sets some variables in Iterator), and it might not be set by the user (.splits()). I don't see a clean way to know if the flag was set by the user or not (without using yet another flag). I'll figure out a way to make it work though.

I updated the docstring and made the version check a bit nicer, as well as added it to iterator.

[mttk]

I also added weak support for torch.device now, as in #294. It's not ideal as I'm just unpacking the device index, but it will take some time to find all the spots where the code breaks if the variable can be either an int or a torch.device instance.

[zshihang]

how about get rid of all the device arguments in torchtext? user could change the device using one-liner.

input, target = input.to(device), target.to(device)

[jekbradbury]

I'm open to either of these solutions, and I'm sorry I haven't been on top of 0.4 compatibility; let's get something merged soon so we have a working release

[mttk]

We could dump the responsibility onto the user (I prefer this as it would make for some cleaner code), but that would kinda ruin backwards compatibility.

[jekbradbury]

I'm OK with 0.4 support being a breaking release

[mttk]

I went on a deleting spree:

• I removed every place that train was passed as an argument, except (1) in the constructor of Iterator, where it is used to set the repeat/shuffle/sort flags and (2) in Batch.fromvars since it was stored during serialization in previous versions, however there it's a no-op and is simply present so that previously stored models can be restored.
• I kept the device argument to be consistent with pytorch's DataLoader (which sets the device internally). However, now the argument has to either be a string or torch.device and is passed to the tensor constructor. In case the argument is an integer, a warning is logged.

Still waiting to see if this passes tests as my server is acting up.

[mttk]

@jekbradbury the current build passes everything. When you get some time, please do a sanity check on the changes, but I don't see any obvious issues.