Consider removing default interpretation of `int` as `int32`

I tried to run the following straigthforward-looking blaze code:

```
In [6]: s = bz.symbol('s', 'var * int')
In [7]: bz.compute(s + s, {s: arange(5)})
```

this results in a big scary traceback terminated in the blaze numba backend with:

```
TypeError: ufunc '' not supported for the input types, and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''
```

Fortunately for me, I sit across from @llllllllll at work, and he informed me that `int` means `int32` in datashape, which triggers this error on the numba backend because I'm attempting to compute an expression of type `int32` against data of type `int64`, which numba rightfully considers unsafe. (It'd be nice if numba told me this information, but that's a separate issue.)

Looking through `type_symbol_table.py`, the interpretation of `int` is just hard-coded to `int32`. Interestingly, `intptr`, is interpreted as "the size of the system int":

```
no_constructor_types = [
...
('int32', ct.int32),
('int64', ct.int64),
('intptr', ct.int64 if _is_64bit else ct.int32),
('int', ct.int32),
...
```

Always interpreting `int` as `int32` seems incorrect to me, given the fact that `np.arange(N, dtype=int)` returns `int64`s on 64-bit machines. There are, I think, two reasonable alternatives:
1. Make `int` mean "system int", i.e., `int` means `int64` on 64-bit machines, and `int32` on 32-bit machines.
2. Disallow `int` entirely in datashape strings in favor of explicitly requiring a size.

While option 1 may seem initially appealing, I'd argue that in the long run it would lead to subtle bugs as people write code assuming that int is 32 or 64-bit, only to encounter failures on other machines. (We've encountered such issues [in zipline](https://github.com/quantopian/zipline/commit/1377d25c9534d3ba72f1a622c5f99607526f3520).)

I'd argue that option 2 is the better solution in the long run. Many datashape users will initially stumble when `var * int` is rejected, but if the parser is made to fail with a clean error indicating that the user should specify `int32` or `int64`, I don't think many people will struggle to adapt their code accordingly.

Additional evidence in favor of deprecating `int` is the fact that `float` and `uint` always require explicit size modifiers (though, interestingly, `real` and `complex` have entries).