Refactor out fsck_object_buffer() accepting the object data

When fsck'ing an incoming pack, we need to fsck objects that cannot be
read via read_sha1_file() because they are not local yet (and might even
be rejected if transfer.fsckobjects is set to 'true').

For commits, there is a hack in place: we basically cache commit
objects' buffers anyway, but the same is not true for tag objects.

By refactoring fsck_object() to take the object buffer as an optional
argument, we prepare the machinery for the upcoming handling of tag
objects.

The assumption that such buffers are inherently NUL terminated is now
wrong, of course, therefore let's pass the size of the buffer as an
additional parameter so that we can add a sanity check later.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure that index-pack --strict fails upon invalid tag objects

One of the most important use cases for the strict tag object checking
is when transfer.fsckobjects is set to true to catch invalid objects
early on. This new regression test essentially tests the same code path
by directly calling 'index-pack --strict' on a pack containing an
invalid tag object.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Make sure fsck_commit_buffer() does not run out of the buffer

So far, we just assume that the buffer is NUL terminated, but this is not
a safe assumption, now that we opened the fsck_object() API to pass a
buffer directly.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>