Fixed a bug where unpacking into a non-pointer would panic.

- The bug was caused by a mistake in pointer-handling logic.
  Because the makeUnpacker function can be called from
  makeFieldUnpacker, it has to handle the case where the type it's
  being called on is not a pointer type (this is fine because the
  corresponding reflect.Value will be derived from a call to
  reflect.Value.Elem(), which means it will be settable). Thus, it
  can't tell the difference between being called on a non-pointer
  type validly (ie, from makeFieldUnpacker) and being called on a
  non-pointer type invalidly (ie, from makeUnpackerWrapper). Thus,
  if the user passed in a non-pointer type that was otherwise valid
  for unpacking, Unpack would attempt to modify it, but its being
  unsettable would cause the reflect package to panic. The fix is
  that makeUnpackerWrapper now explicitly checks for this edge case,
  and returns a no-op unpacker.
- Additionally, though not technically necessary to fix the above
  bug, the four main helper functions (those other than *Wrapper)
  return errors instead of simply returning packers or unpackers
  that will panic upon execution. This way, makePackerWrapper and
  makeUnpackerWrapper know whether an error has occurred, and can
  be more intelligent based on that knowledge. Currently, this means
  that any errors returned will be panicked on immediately rather
  than after prior successful operations have taken place (for
  example, it used to be the case that a panic related to an invalid
  field would only happen after previous fields had been properly
  processed). More importantly, this also means that, if an invalid
  type is passed to Unpack, but it's passed as a non-pointer value,
  Unpack will panic instead of being a no-op.