[extfs] fix inodes not being initialized above 4 GB

* So, as it happens, when assigning the product of two 32-bit variables into a 64-bit one,
  compilers default to being *DUMB* and, against all reasonable expectations, do not perform
  that multiplication as a 64-bit operation (even when the code is compiled as x64). Wow,
  that's really great decision making by compiler designers if I ever saw some... Whoever
  decided that C developers would much rather want truncation and 32-bit overflows, instead
  of the expected *LOGICAL* behaviour of conducting arithmetic operations as 64-bit when the
  result will be assigned to a 64-bit variable, need to be condemned to a lifetime of trying
  to help elderly folks trying to conduct simple computing tasks as a punishment...
  Anyhoo, nt_write_blk()'s offset.QuadPart = block * channel->block_size + nt_data->offset
  was overflowing 32-bit as soon as block * channel->block_size went over the 4 GB mark,
  with the disastrous results one can expect. Considering that this is code we practically
  lifted verbatim from e2fsprogs, I guess e2fsprogs' NT I/O manager was never properly
  tested with anything larger than a 4 GB. Awesome!
* We fix the above by doing what unix_io.c does and setting the 32-bit read/write_blk()
  calls to be wrappers around their 64-bit counterpart (since, once you deal with a 64-bit
  block variable, the computation is conducted as 64-bit).
* Also remove a bunch of stuff we don't need from config.h
* Closes #1396

src/format_ext.c

@@ -376,8 +376,6 @@ BOOL FormatExtFs(DWORD DriveIndex, uint64_t PartitionOffset, DWORD BlockSize, LP
 		goto out;
 	}
 
-	// TODO: mke2fs appears to be zeroing some data at the end of the partition as well
-
 	ext2_percent_start = 0.0f;
 	ext2_percent_share = (FSName[3] == '2') ? 1.0f : 0.5f;
 	uprintf("Creating %d inode sets: [1 marker = %0.1f set(s)]", ext2fs->group_desc_count,