Fix an inode bitmap scanning bug. Due to an error in the length adjustment

Fix an inode bitmap scanning bug.  Due to an error in the length adjustment
the first scanned byte of the inode bitmap could be checked twice under a
specific and rare but intentionally reproducable set of conditions.  This
resulted in a sanity check failing and a panic.  The required conditions are:

* Very few available inodes in the cylinder group.

* All available inodes are still in the inode hashmap (related vnodes have
  not been completely destroyed yet) and thus skipped.

* The first scanned byte (indexed by the rotor) contains one of these
  not-quite-free inodes.

It should be noted that even though this error exists in FreeBSD-4, the
conditions never occur to trigger it becaues FreeBSD-4 will reuse a vnode
that is still not completely destroyed.  DragonFly does not reuse such vnodes
because they represent a weird and fairly rare code situation that could
lead to bugs, and because attempting to reuse such vnodes/inodes represent
potential stall points.

Found-with: blogbench script provided by Tomaz Borstnar.