Support MKL2017 DNN API

[i8run]

Current support:

1. convolution
2. pooling (max and average)
3. relu
4. batch normalization
5. lrn
6. linear

[jason-dai]

We should perform the scala <-> MKL layout conversion check in scala code instead of c++ code; in particular:

1. Within Sequential, a module is connected to just one other module; however, within other types of Container, a module can be potentially connected to multiple modules, or vice versa; the current logic only works for Sequential, not other types of Container (such as Concat)
2. We can define multiple engines such as Scala, MKL, MKL-DNN, etc. in DL-lib, and every module can have an engine method that returns what engine it is running on. Then for each MKL module, we can easily determine whether its input/output belongs to another MKL engine (in a fashion similar to how updateOutput and updateGradInput are implemented for Container) or conversion is needed.
3. We can also define a MklTensor representing the storage whose layout is managed by MKL; in addition to the conventional Tensor dimension information, it also maintains the MKL layout struct (preferably using a Scala variable). Then one can easily convert it to a DenseTensor using these information; in addition, it should only support a limited subset of Tensor operations (maybe only those treating it as a one-dimensional array).

And also maybe we can create a MKL2017 branch to start better integration.

[i8run]

1. Yes, current logic only works for Sequential. It will ignore the Concat layer, and will be supported in the next two commits with Concat layer of mkl dnn version.
2. Currently, I try to avoid changing existing architecture too much, so I put some methods in native code. And each class like SpatialConvolution in scala only saves a pointer to the class in the native code, which is initialized at the first forward procedure.
3. If we have some methods to convert the layout managed by MKL to Tensor, it's also very helpful for debugging. And it will be supported after the performance meets requirement.
4. Because the concat which uses mkl dnn api comes soon, I will create a branch named MKL2017 after the commit. The tests show that the throughput is 30+ images/s from 20 images/s for GoogLeNet V2. But it needs more test and tune.

[jason-dai]

I think we can close this PR and make the current implementation/prototype for MKL2017 support a separate branch; in this way, we can first focus on the performance and have others to test that (e.g., for distributed training). We will need more work to refine and refactor the code before it can be merged, but that could happen after we get reasonable performance.