fix out of order read for some tiff

Make sure we always have min of two strips in a linecache. Plane
separate tiffs with large rows-per-strip could shrink the cache to a
single block of pixels, which would then fail if the output straddled a
tile boundary.

See #1158

Thanks @chregu for the report.

libvips/conversion/tilecache.c

@@ -939,8 +939,14 @@ vips_line_cache_build( VipsObject *object )
 	/* Output has two buffers n_lines height, so 2 * n_lines is the maximum
 	 * non-locality from threading. Add another n_lines for conv / reducev
 	 * etc. 
+	 *
+	 * tile_height can be huge for things like tiff read, where we can
+	 * have a whole strip in a single tile ... we still need to have a
+	 * minimum of two strips, so we can handle requests that straddle a
+	 * tile boundary.
 	 */
-	block_cache->max_tiles = 3 * n_lines / block_cache->tile_height;
+	block_cache->max_tiles = VIPS_MAX( 2, 
+		3 * n_lines / block_cache->tile_height );
 
 	VIPS_DEBUG_MSG( "vips_line_cache_build: n_lines = %d\n", 
 		n_lines );

libvips/foreign/tiff2vips.c

@@ -2049,6 +2049,9 @@ rtiff_read_stripwise( Rtiff *rtiff, VipsImage *out )
 
 	}
 
+	/* rows_per_strip can be very large if this is a separate plane image,
+	 * beware.
+	 */
 	if( 
 		vips_image_generate( t[0], 
 			NULL, rtiff_stripwise_generate, NULL, 
@@ -2059,7 +2062,6 @@ rtiff_read_stripwise( Rtiff *rtiff, VipsImage *out )
 		rtiff_autorotate( rtiff, t[1], &t[2] ) ||
 		rtiff_unpremultiply( rtiff, t[2], &t[3] ) ||
 		vips_image_write( t[3], out ) )
-
 		return( -1 );
 
 	return( 0 );