Add pytorch interface to ATen Dialect

[stephenneuendorffer]

This patch adds a pytorch interface to npcomp. This interface is modeled
after pytorch_xla and exposes the MLIR-based flow as a virtual device (similar
to a gpu device or an xla backend). Usage is something like:

dev = torch_mlir.mlir_device()
t0 = torch.randn((4,4), device=dev)
t1 = torch.randn((4,4), device=dev)
t2 = t0 + t1
t2_mlir = torch_mlir.get_mlir( t2 )
t2_cpu = t2.to('cpu')

In this case t2_cpu contains the result of the computation, and t2_mlir
contains the mlir description of the computation. Note that this also
properly returns backward paths synthesized by pytorch. There are roughly
speaking three parts of this:

1. A tensor type (implemented by Tensor.* and TensorImpl.*)
2. The device modeling (ATenMLIRBridge, ATenMLIRDevice, ATenMLIRType)
3. a temporary IR (implemented by ir.cpp)
4. The driver that uses the IR to generate MLIR, run Passes and compile the
   result using mlir::ExecutionEngine (implemented by jit.cpp and
   MLIRGenerator.cpp)
5. A runtime library implemented by lib/aten_ops.cpp

Particular feedback that would be useful include:

1. how do we merge the runtime library and jit infrastructure with what is
   being done for numpy?
2. Suggestions about naming, or how to merge this into the existing directory
   hierarchy. Currently it seems like a bit of a blob with everything depending
   on everything else. There's also some function definitions that don't live in
   the file corresponding to their declaration.
3. It's unclear to me how much of the 'IR' is necessary, or whether we should
   just create MLIR on the fly.

Some aspects of this are known to be less than optimal, in particular:

1. Some files don't follow the LLVM naming convention. pragma once is used
   everywhere (pending file renaming)
2. It's unclear how much of the complexity inherited from pytorch_xla is
   necessary, is something simpler sufficient, or should pytorch_xla be extended,
   or should we keep the complexity and support backend devices like pytorch_xla,
   or will there be a different model about how backend devices are handled.
3. More aspects of this (e.g. the IR) seem like they should be automatically
   generated.
4. The tests should get moved around and live with the existing tests.

[silvasean]

First round of comments.