WIP: patches for TensorOperations.jl

Dear Tim,

this is my first attempt at making some changes to cartesian.jl. I have added the possibility of having multiple dimensionality parameters as a tuple (N1,N2,...) and added a call to `exprresolve` for the `bodyfunc`, so that one can use `@nloops` and friends with simple arithmetic expressions.

Some questions/issues remain.
1) I wanted to add the possibility to specify the dimensions to explicitly build in the macro syntax, so that you could do something like 
```julia
@ngenerate N returntype SOME_CONSTANT_LIST function f(...)
end
```
However, I don't know how to force evaluation of SOME_CONSTANT_LIST in the module where this macro is called, so I now call this is
```@eval @ngenerate N returntype $SOME_CONSTANT_LIST function f(...)```
and then use the code in line 48 and 52 to assign the value in args[1] to dims. There is probably a better way to do this, but I am still learning to understand all the subtleties of  `esc` and `$(Expr(:quote,...))` etc.

2) I have 2 separated methods for the `ngenerate` function, one where `itersym` is a Symbol (your original version) and one where `itersym` is a tuple of Symbols. In the latter one, I decided to remove all splatting functionality since it seemed like a hassle to make this work with splatting (I also don't see a use case where you have different parameters N1, N2, etc and you want to splat with respect to one of them). 

3) There was still a Base.Cartesian in your original `ngenerate` function, which I replaced (line 129). Another issue with this line. It calls `generate1` with as first argument `$(symbol(itersym))` and another argument `$itersym`. I was thinking that this corresponds to having the first argument of `generate1` of type `Symbol`, and then the other argument, called `N`, of type `Int`, when this function is generated. However, it turns out that `$(symbol(itersym))` and `$itersym` produce the same AST, so that I had to define a method definition for `generate1` where the first argument is of type `Union(Symbol,Int)`. This strikes me as unintended behaviour. The fact that this still works is because all `N`'s in the prototype also get replaced by their integer value, and thus the `sreplace!` in `generate1` isn't really doing anything anymore (as far as I can tell, I am not very qualified in examining this kind of metaprogramming).




It could be the case that the common cases, the ones you want to generate, don't have a simple (1:4, 1:4) pattern, so I wanted the ability to just specify a list of tuples, e.g. `[(1,1),(2,1),(2,2),(3,1),(3,2),(3,3)]`. For the case with 3 parameters,  I found it more aesthetic to first assign this list to a constant variable, and then just putting the name of the variable there. Hence the `@eval` construction. But the `args[1]` in the line above should anyway be enclosed by an eval, such that it gets properly evaluated if an expression is used for dims.