Use dynd's ability to construct from iterators instead of a separate fromiter method
Tweak the constructor to use the udtype or dtype dynd constructor depending on the input
Add special-casing for barray so it handles iterators as before
Add field access to record arrays via attribute lookup, improve record array support
Fixed a bug in cache code for getting a single element
Tweak the injected record properties slightly
Update to reflect dynd rename of nd.dtype to ndt.type
Updates to reflect cleaning up of dtype/type usage in dynd
Remove the aterm sublibrary
Remove blir/cgen
Updates to the blaze-web server for dynd changes
Remove some unused files

NOTE: These may be worth revisiting in the future, by reviewing
      the git history, but right now culling dead code is much
      more important to speed up development.
Remove some more unused code
Reverse the logic of py3help into py2help
Simplify/remove code from coretypes.py
add a basic mailmap file
The default value of a datetime cannot be serialized with JSON.  Use a 0 int instead.
Fixed a nasty bug with strings being larger than BLOSC_MAX_TYPESIZE

This was a fundamental flaw in BLZ/Blosc.  In theory, the itemsize in Blosc
would only be used for determining the amount of bytes to be shuffled, but
in practice this is used in getting a number of 'items' in the
`blosc_getitem` call.  So that means that itemsizes cannot be larger than
BLOSC_MAX_TYPESIZE (currently 255).

The main problem with this were strings, because NumPy reports them as
having a typesize equivalent to its size, and that means that the
BLOSC_MAX_TYPESIZE value can easily be reached.  Now, the string
case is specially treated and the itemsize is 1 for byte strings
and 4 for Unicode ones.  This also allows for better behaviour of
the shuffle filter.

In the future, DyND would provide more flexibility for dealing with
the actual itemsizes, but meanwhile this workaround is the way to go.
The metadata info for columns drops the paths.

Having the complete paths in the dirs metadata prevented a safe
operation when moving the tables to different directories,
or just when loading tables from different places that they where
created.

One issue that appeared while doing the fix is that, when a new
column in-memory is inserted, it is not clear which should be the
default action (copy on-disk or just use the reference?).  Probably
we would need to setup a configuration file for specifying default
actions.  For the time being, the reference will be used.
Merge branch 'master' into vtable