In commit 7ec7aa4a7 (odb: assert on logic errors when writing objects,
2018-02-01), the check for whether we are trying to overflowing the fake
stream buffer was changed from returning an error to raising an assert.
The conversion forgot though that the logic around `assert`s are
basically inverted. Previously, if the statement

    stream->written + len > steram->size

evaluated to true, we would return a `-1`. Now we are asserting that
this statement is true, and in case it is not we will raise an error. So
the conversion to the `assert` in fact changed the behaviour to the
complete opposite intention.

Fix the assert by inverting its condition again and add a regression
test.

Return an error to the caller when we can't create an object header for
some reason (printf failure) instead of simply asserting.

There's no recovery possible if we're so confused or corrupted that
we're trying to overwrite our memory.  Simply assert.

Provide error messages on hash failures: assert when given invalid
input instead of failing with a user error; provide error messages
on program errors.

It's unlikely that we'll fail to allocate a single byte, but let's check
for allocation failures for good measure.  Untangle `-1` being a marker
of not having found the hardcoded odb object; use that to reflect actual
errors.

At the moment, we're swallowing the allocation failure.  We need to
return the error to the caller.

The streaming read functionality should provide the length and the type
of the object, like the normal read functionality does.

The null OID (hash with all zeroes) indicates a missing object in
upstream git and is thus not a valid object ID. Add defensive
measurements to avoid writing such a hash to the object database in the
very unlikely case where some data results in the null OID. Furthermore,
add shortcuts when reading the null OID from the ODB to avoid ever
returning an object when a faulty repository may contain the null OID.