build: don't interpret Strings as base64

Only Buffers (Node.js) and/or Typed Arrays/ArrayBuffer (dual-sided)
should be interpreted as `<data>`. Strings should only end up
as `<string>s`.

Also, this addresses the unescaping fix referenced in #44.
parse: always return a Buffer for <data> nodes

Before, a <data> entry would always return a String,
decoded as UTF8. Now it always just returns the Buffer instance,
and the user can decide what to do with it.
build: use .txt() for the "date" value

The ISO date string should never have any invalid chars
in it anyways, but just to be safe...
build: slight cleanup and optimizations
build: more lint
build: add support for Typed Arrays and ArrayBuffers

This makes it possible to encode `<data>` elements
from within the browser (since the Buffer constructor
isn't available there)
build: fix encoding a typed array in the browser

The "length" hack I was doing doesn't work in real web browsers.

The Node.js implementation of the ArrayBuffer is non-standard
in that it allows bytes to be accessed via index.

In real web browsers you need to wrap the ArrayBuffer
with a Uint8Array, which properly includes the "length" property.
Merge pull request #47 from TooTallNate/update/better-buffer-type-detection

Better buffer type detection