Do not crash when handling files of exactly maximum allowed size

Test case:

1) Mount geesefs with --part-sizes 5
2) Reproduce the bug with the following bash script:

   ```
   perl -e 'open FD, ">test-will-die"; sleep 20' &
   dd if=/dev/zero of=test-will-die oflag=direct bs=1M seek=0 count=200
   dd if=/dev/zero of=test-will-die oflag=direct bs=1M seek=49999 count=1
   sleep 20
   ```

   I.e. to reproduce the bug, you should have the last write to an inode end
   at maximum possible file offset, it should also have more modified data
   than just the last part, and there should be an open file descriptor for
   that file.

internal/file.go

@@ -64,6 +64,10 @@ func (fs *Goofys) partNum(offset uint64) uint64 {
 		start += s.PartSize * s.PartCount
 		n += s.PartCount
 	}
+	if offset == start {
+		// Sometimes we use partNum() to calculate total part count from end offset - allow it
+		return n
+	}
 	panic(fmt.Sprintf(
 		"Offset too large: %v, max supported file size with current part size configuration is %v",
 		offset, start,