[Anniversary] [th01] Endings: Fix the ドカーン image tearing issue

ZUN's intention is obvious here.

Part of P0239, funded by Ember2528.

th01/end/end.cpp

@@ -311,33 +311,10 @@ void near shake_then_boom(int shake_duration, int boom_duration)
 		if((i & 3) == 0) { graph_scrollup(8); }
 		/*       */ else { graph_scrollup(0); }
 
-		end_pic_show_and_delay(1, 2);
-
 		if(i & 1) {
-			// ZUN bug: No delay after rendering this image. Unlike the
-			// z_vsync_wait_and_scrollup() function used in REIIDEN.EXE,
-			// master.lib's graph_scrollup() doesn't wait for VSync, causing
-			// this image to immediately be overwritten with pic #1 on the next
-			// iteration of the loop...
-			//
-			// ... or so you would think. Turns out that EGC inter-page copies,
-			// as used by end_pic_show(), are *really* slow. Combined with the
-			// usual slowness of PC-98 VRAM, you'll still end up seeing at
-			// least parts of the "boom"/"ドカーン" image even on faster PC-98
-			// systems before it's fully overwritten on the next iteration.
-			//
-			// Technically this could be considered a quirk, as the resulting
-			// frame drops affect the length of the ending. On the other hand,
-			// we explicitly judge observability in terms of an infinitely fast
-			// PC-98. Such a system would consequently never show this image
-			// that ZUN clearly intended to show, thus turning this into the
-			// exact definition of a bug.
-			end_pic_show(2);
+			end_pic_show_and_delay(2, 2);
 		} else {
-			// And why are we re-showing the same pic here? Redundant,
-			// obviously – there are much better ways of intentionally burning
-			// CPU cycles.
-			end_pic_show(1);
+			end_pic_show_and_delay(1, 2);
 		}
 	}
 }