Don't allocate buffers for huge tag offsets

- There seems to be a relatively common corrupt tag which has an offset
  of MaxUint32. This is probably not a valid offset, so return early
  before we allocate a slice this large.
- Read tag values into a bytes.Buffer. This will prevent allocating
  memory beyond the size of the image file in the event that a tag is
  invalid or corrupt.
- Fixes issue #20
Add tests for bad exif tags

- Verify that we error out immediately when an exif tag Count is
  MaxUint32, which is likely invalid.
- Verify that we don't try to buffer more than the size of the image
  file if the tag has an extraordinarily large Count.
Abort on 0-length tag value or recursive IFD

- Might be caused by an unknown DataType, or a Count of 0, but either
  way the tag is invalid
- Check for immediate recursion when decoding IFDs. The 0-length check
  above will prevent the obvious case, but it still could be possible to
  have a self-referencing directory. This doesn't check for indirect
  recursion. Maybe there should be a limit to the number of times
  DecodeDir can be called?
Add another corrupt image and test

- check for 0-length tag value
Decode: better effort in case of failure

Context: https://code.google.com/p/camlistore/issues/detail?id=493
Short version: when decoding fails because of e.g a particular tiff tag,
some/most of the rest of the decoded information could still be used.

This change is two-fold:

1) it provides some helper functions to diagnose the error returned by
Decode, and help decide whether the returned decoded information can
stil be used.

2) because sub-IFDs are independent, if parsing one of them fails,
the error is recorded but parsing the others is still attempted.
Merge pull request #28 from mpl/go1
more careful handling of offsets and memory. fixes #20 and #30. Thanks @jbardin