This reverts commit 4f2f9044e60d16b189cd13acf41089dd83c79c0e.
Reintroduces errors from `UndefinedValue()` when the undefined-type is
unhandled.
- We now just return it rather than panic with it so that we can check
for it directly rather than use `log.Is()`.
- We've updated the checks across the code accordingly.
The upshot of this is that generating a list of type-correct slices or a
string from a tag's value is now stupidly easy.
- Broke parsing into an independent type (parser.go:Parser).
- Moved primary value-processing logic to `ValueContext` so that it
coexists with the actual data (though as much basic functionality as
possible is implemented independently and reused here). This
eliminates extremely ridiculously obtuse usage procedure.
- Deprecated almost all existing TagType functionality (in order to
distance us from this now-legacy usage pattern). Existing
functionality maintained for now. We'll drop it when we do the next
release major.
- `ValueContext` is now passed by reference.
Added a `Size()` method to it and decommissioned redundant
`TagTypeSize()` and `(TagType).Size()`.
- ifd_enumerate.go: Moved `ValueContext` definition to
value_context.go .
- These are absolute representations of where an IFD is positioned with
respect to the other IFDs. There is a more-specific, "fully-qualified"
form of the IFD-path that allows you to express indices in order to
refer to specific siblings.
- Eliminates issues with IFDs at different levels potentially having the
same name (if that's what is required with a certain dataset/
datasource).
- There is a specific IFD registry that controls the heirarchy of IFDs
that we recognize and the tags associated with the child IFDs. This
allows custom hierarchies replacing even the TIFF specification for
which are expected in an image (so we can read other types of images
or any potential IFD hierarchy, even non-image ones).
- IFD and IB instances embed the IFD-path and FQ IFD-path that they were
found or built for.
- Added some assertions and constants. Renamed from variable so it'd be easy to
tell if the byte-arrays, even though they come directly from the EXIF, which
specific offsets they start at (so no remove for confusion during enumeration
and building).
