With the previous commit, we restore the objcore's oa_present field
when we first read the object.

On top of that, it would be nice if we could restore the field or at
least the bit for OA_VARY when we read the log, because a cache lookup
checks it and could avoid reading objects if the OA_VARY bit is not
set.

On the other hand, if vary is used, the object needs to be read
anyway, so restoring oa_present during log read only payed off for no
vary.

The straight forward solution would be to add 2 bytes to struct
fellow_dle_obj. This would

- require a DLE version bump and compatibility code
- bump the dle size from 72 to 80 bytes (because alignment)
- consequently, reduce FELLOW_DISK_LOG_BLOCK_ENTRIES from 56 to 4032 /
  80 = 50

All this is possible and part of the fellow design, but at
this point I conclude that it is not worth the effort.

Another option would be to cram two bits into the existing
fellow_dle_obj, for example by exploiting the fact that the sign bit
of ban and t_origin is always zero. This could break backwards
compatibility, so we prepare for the option, but do not implement it.

All in all, we just add a TODO to add this when we need to extend the
DLE anyway.

Closes #17