[bugfix] do not reuse an out-of-range last allocated block hint

[WaberZhuang]

The allocation hint cached in fs->reserved[3] is the block right after the
last allocated range, so it equals blocks_count as soon as an allocation ends
at the last block of the file system. ext2fs_new_range() used it as the search
start unconditionally (the s_first_data_block fallback was commented out), so
ext2fs_find_first_zero_block_bitmap2() rejected the range with
EXT2_ET_INVALID_ARGUMENT:

Illegal block number passed to ext2fs_test_block_bitmap #8192 for block bitmap

From then on every allocation without a goal of its own failed, although the
file system still had free blocks. A zero hint is equally unusable when
s_first_data_block is 1 (1KB block size), because block 0 is outside of the
block bitmap - there the very first allocation already fails.

ext2fs_fallocate() had the same problem and additionally overwrote the goal
given by its caller, which made the upstream ~0ULL sentinel (and with it
ext2fs_find_inode_goal()) unreachable, since reserved[] is 32 bit.

Changes:

• ext2fs_new_range(): fall back to s_first_data_block when the hint is 0 or
  outside the file system.
• ext2fs_new_range() / ext2fs_new_block3(): only cache a hint that is inside
  the file system and fits in the 32 bit reserved[] slot, otherwise store 0, so
  a truncated block number can never be used as a goal (this also removes the
  not 64-bit safe case for filesystems beyond 2^32 blocks).
• ext2fs_fallocate(): only follow the hint while it points inside the file
  system, and